The NAC labyrinth
Cisco's Network Control
Cisco's Network Admission Control can be directly mapped to TCG's NAC
architecture. However, because Cisco is bound by the revenue reality of its
installed base, the architecture comprises both compromises in and extensions
beyond what TCG offers.
On the client side, TCG's Network Access Requestor and the Trusted Network Connect
client are covered by free Cisco Trust Agent software. TCG's Integrity
Measurement Collectors appear in the Cisco model as vendor-provided agents and
as (optionally) Cisco's own Cisco Secure Access product, a host
intrusion-prevention system it picked up with its 2003 Okena acquisition.
Cisco has had to get serious about the protocols needed to handle Network
Admission Control. At the lowest layer, Cisco selected the Extensible
Authentication Protocol (EAP). While EAP was designed by the IETF for authentication
and is used in most 802.1X deployments, Cisco has developed its own proprietary
(but publicly disclosed) EAP method, called EAP-FAST (Flexible Authentication
via Secure Tunneling). With EAP-FAST in place, Cisco can include 802.1X
authentication as well as endpoint security assessment information wrapped
inside the EAP protocol.
Because Cisco wants its product line to work with more than 802.1X-enabled
switches, Cisco Trust Agent has EAP-over-802.1X and EAP-over-User Datagram
Protocol (UDP) support. With this dual protocol support, when an end system
tries to access the network using a method other than 802.1X, such as a VPN
client or someone coming in through a non-802.1X switch, the EAP traffic
travels over UDP instead of directly in Ethernet frames.
The critical difference between the 802.1X and UDP versions of Cisco's EAP,
however. In the 802.1X case, EAP includes authentication and endpoint security
assessment information. When used with UDP, Cisco's NAC no longer does
authentication. Instead, the user has to be authenticated via some other
mechanism, and the authentication and user credentials are no longer tightly
tied to the security policy for that user.
This lack of symmetry between 802.1X and UDP versions of Cisco's Network
Admission Control means that access and authentication are handled differently
depending on whether you are connecting via LAN, wireless LAN or over a VPN
tunnel.
A further symptom of this unequal support is the lack of wireless support in
the free Cisco Trust Agent. For wireless 802.1X, network managers will have to
replace the freeware Cisco Trust Agent 802.1X with a different 802.1X
supplicant from Meetinghouse Data Communications or Funk Software (now
Juniper). The real focus of the current version of Cisco's Network Admission
Control is endpoint security assessment -- the authentication that comes out of
the 802.1X dialog is really a fortunate side effect.
As a dominant manufacturer of switches, routers and VPN devices, Cisco is
shouldered with the difficult task of incorporating Network Admission Control
into its devices. TCG's policy enforcement points equate in Cisco's
architecture to network access devices. Cisco has pages of documentation
explaining which devices will support the different client scenarios: EAP over
UDP and EAP over 802.1X.
Summarizing those charts is difficult and subject to dissension; Cisco's
competitors cite the requirement to upgrade all switches as a major
disadvantage of Cisco's approach, while Cisco believes the majority of enterprise
customers interested in Network Admission Control have the right equipment in
place and can start using it immediately.
One very clear issue is that the policy-enforcement capabilities of different
devices vary widely. Sending full, fine-grained access control policies to the
policy enforcement point will only be possible in networks with limited sets of
devices, such as Cisco's high-end 6500 switches. Cisco's support of more
coarse-grained access control, such as virtual LAN-based isolation or even wholesale
go/no-go access to the network, comprises the capabilities of most Cisco
products available today.
Cisco offers a second approach to its Network Admission Control with the Cisco
Clean Access appliance, picked up with the 2004 Perfigo acquisition. This
appliance is shoe-horned into Cisco's NAC strategy for companies that want
endpoint security assessment, but don't want to change their infrastructure to
get it. The long-term integration between the Clean Access server, the Clean
Access agent and a general NAC scheme is uncertain, largely represented by
malleable PowerPoint slides that are likely subject of ongoing debate within
Cisco.
The Cisco equivalent to the TCG's back-end policy decision point is Cisco's
access control server and a series of interfaces to third-party policy,
authentication and audit servers. Access Control Server, Version 4.0 or higher,
represents the Cisco version of a TCG network access authority combined with
the Trusted Network Connect server. Integrity measurement verifiers, called
policy server decision points in Cisco's architecture, connect to the Access
Control Server using Cisco-defined protocols.
Cisco's architecture reaches beyond TCG's NAC plan with audit servers, which
audit the endpoint security status of devices that do not have the Cisco Trust
Agent installed on them. When an agentless system tries to connect to a network
protected by Network Admission Control, the policy enforcement point (network
access device in Cisco's terminology) can detect there is no agent. It then can
sic an audit server on the end system, either by trying to scan the system from
the outside or by trying to download agent software into the browser allowing
an audit to occur. Although the audit server fills an architectural hole, it's
not very clear how much useful data it will collect or whether it will be
sufficient to set network access policies upon.
Cisco's Network Admission Control architecture is a serious one, and it is
backed up by decent support throughout Cisco's product line. There are some
ugly spots, though, such as the lack of policy integration when using
non-802.1X methods. However, Cisco has struck a good balance between what is
architecturally elegant and what works in existing enterprise networks. If
there is a weak spot in Cisco's architecture, it's the intense focus on
endpoint security and relative inattention paid to detailed access controls and
authentication.
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.
As with Trusted Network Connect, the Microsoft client side 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. More
importantly, 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.
Back to top
 Click here to submit a story for consideration by Cram Session Editor, stories@cramsessionnac.com
|
