NAC competition: Microsoft's Network Access Protection

No switch or router maker, industry giant focuses on DHCP for access control.

The most significant differences between Microsoft's Network Access Protection architecture and TCG's Trusted Network Connect result from the fact that Microsoft doesn't make switches or routers. Therefore, the path for handling enforcement is different, focusing on the SMB-friendly DHCP rather than enterprise-sized 802.1X, though the architecture gives a nod to the latter as an option.

As with Trusted Network Connect, the Microsoft clientside is broken into three parts.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

Click to see: Clear Choice Analysis logo

The most significant differences between Microsoft's Network Access Protection architecture and TCG's Trusted Network Connect result from the fact that Microsoft doesn't make switches or routers. Therefore, the path for handling enforcement is different, focusing on the SMB-friendly DHCP rather than enterprise-sized 802.1X, though the architecture gives a nod to the latter as an option.

As with Trusted Network Connect, the Microsoft clientside is broken into three parts.

At the top are the Microsoft System Health Agents, taking on the function similar to Integrity Measurement Collectors. These agents are responsible for generating Statements of Health that can be used to assess endpoint security.

Tying the System Health Agents into the rest of the architecture is Microsoft's Network Access Protection Agent, analogous to TCG's Trusted Network Connect Client. Below the Network Access Protection Agent are Microsoft's Enforcement Clients, which line up with TCG's Network Access Requestor.

These Enforcement Clients, typically 802.1X supplicants or VPN clients in other architectures, also include DHCP client capabilities in Microsoft's world.

Microsoft's architectural white papers define clients for DHCP, Point-to-Point Protocol/Layer 2 Tunneling Protocol (PPP/L2TP), and IPSec network access. What is more important, though, is that Microsoft has defined the API connecting its three layers of Network Access Protection on the client.

By creating an API that describes how the three pieces of the client will fit together, Microsoft eliminates an enormous amount of risk and variability in the entire Network Access Control space. Even if Microsoft's entire Network Access Protection product plans were jettisoned internally, the contribution of having these defined APIs shipping with Windows cannot be underestimated.

Of course, the trick will be convincing every other NAC architect in the industry that Microsoft's API is both necessary to a good NAC design and sufficient for the task. No vendor is proposing to make this middleware piece a moneymaking differentiator. It simply exists to let desktop security vendors have a way of communicating the status of their products back to the Policy Decision Points. By simply adopting Microsoft's model, which happens to mesh almost perfectly with the other important NAC models, IT managers won't have to worry about interoperability or vendor lock-in at that point in the scheme.