NAC competition: Microsoft’s Network Access Protection

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 – although the architecture gives a nod to the latter as an option.

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.

The role of Policy Enforcement Point in Microsoft’s architecture is assumed by Enforcement Servers. Because Microsoft doesn’t make switch or router hardware, its engineers originally envisioned access control enforcement as a service rather than a choke-point type control that a company such as Cisco might consider as the more natural approach.

With Vista/Longhorn, Microsoft says it will release Enforcement Servers as part of its own Routing and Remote Access Service (RRAS)-based VPN servers, operating both at the Point-to-Point Tunneling Protocol and L2TP layers as well as at the IPSec layer. It’s very clear from the public documents Microsoft has released that it views Network Access Protection primarily as a tool for giving users either no access, full access, or limited access to some sort of remediation and quarantine network.

The lack of a firm place for authentication in Microsoft’s architecture shows that this product family is primarily designed to help existing managed desktops and laptops in a Microsoft domain environment stay compliant with end point security policies, rather than as a generic network access control mechanism.

At the back end Policy Decision Point, Microsoft offers its new Network Policy Server, a RADIUS-based server replacing Microsoft’s older Internet Authentication Server. Network Policy Server will ship in new versions of Windows. The Network Policy Server contains the functionality of TCG’s Network Access Authority, including authentication and policy management, with a separate Network Access Protection Administration Server, which handles the same functions of the TCG’s Trusted Network Connect Server component, gluing the authentication server to third-party health verifier plug-ins. On top of the Administration Server, using a Microsoft-defined API, are System Health Verifiers, the equivalent of TCG’s Integrity Measurement Verifiers, which receive Statements of Health from System Health Agents on the client and provide answers back to the Administration Server.

Like the TCG architecture, Microsoft’s Network Access Protection is accompanied by a great deal of hand waving when it comes to the actual protocols and data streams involved in making the client, the Enforcement Server, and the Network Policy Server all talk to each other. In the case of Microsoft’s original DHCP and RRAS-based Enforcement Servers, it’s all Microsoft software, so having an open protocol is not really critical. However, when it comes to the 802.1X Enforcement Servers, currently available public documents leave a great deal unsaid as to how this will actually work.

Microsoft also throws an interesting monkey wrench into the works with its concept of a “Health Certificate.” Using a combination of existing products to create a Web-based public-key infrastructure server called a Health Certificate Server, Microsoft’s NAC scheme supports creating a digital certificate that can be used in place of Statements of Health.

Rather than try and send Statements of Health around at authentication time, a client proves its health to the Health Certificate Server using normal System Health Agents and Statements of Health. It then receives a digital certificate that it can use instead of normal user credentials for authentication using 802.1X or IPSec. Using certificates in this way is a logical outgrowth of Microsoft’s VPN strategy, in which the IPSec authentication is largely irrelevant; instead, the L2TP authentication that Microsoft clients run on top of IPSec is where the user actually proves his identity.

The benefits of this complex system of using Health Certificates are not clear. It’s likely the goal is to increase perceived performance by separating out the work of determining system health from actually connecting to network resources. Whether this perception will be worth the increase in complexity and decrease in security is a difficult call to make at this stage in the NAC product life cycle.

Next: Juniper’s effort >