Wave Systems Corp. (fka WAVXQ)

[Fullmoon]

What's Up With NAC Standards?

http://www.wwpi.com/networking/featured-articles/6893-whats-up-with-nac-standards

Thursday, 02 April 2009 08:06 Lisa Lorenzin for Trusted Computing Group
For those considering a Network Access Control (NAC) deployment, one of the biggest challenges is the state of the standards and how they relate to current NAC offerings. While a viable solution needs to address security and monitoring as well as networking aspects, its ability to adapt to future changes could be critical. Open standards available today help ensure that NAC solutions implemented at present will both work with the current network and endpoint environment and offer a strong foundation for future growth.

Evolution of NAC Architectures

Over the past six years, NAC frameworks have evolved from proprietary beginnings to today's open standards-based architectures. From a historical perspective, Cisco announced its Network Admission Control (NAC) program in 2004. The C-NAC architecture included an endpoint running a NAC Agent, a Network Access Device, and an authenticator running a NAC Manager. C-NAC addressed the need to apply policy-based controls to a device requesting access to the network. They achieved this goal by offering a proprietary solution that included a client software component -- which supplied information about the endpoint, a management component -- which made the decision whether to permit or deny access, and an enforcement component -- which applied the access control decision.

Another proprietary framework, Microsoft’s Network Access Protection (NAP) Platform Architecture, was introduced in 2004. The Microsoft architecture included a NAP Agent on the endpoint and a Network Policy Server for management, and used Statements of Health (SOHs) to validate the health of the endpoint. Also in 2004, the Trusted Computing Group (TCG), an industry consortium dedicated to strong security through open standards for trusted computing, established a group - Trusted Network Connect (TNC) - with the goal of creating an open architecture for Network Access Control. (Network Access Control has become the commonly-accepted meaning of the acronym "NAC" in the industry today.)

Similar to the Microsoft and Cisco frameworks, the TNC architecture identified an Access Requestor (AR), the endpoint requesting access to the network, which runs a TNC Client to provide health information; a Policy Enforcement Point (PEP), such as a switch, wireless access point, or gateway, which allows or denies access; and a Policy Decision Point (PDP), which evaluates endpoint health, determines what policy to apply, and provisions policy to the PEP. Unlike the preceding proprietary solutions, the purpose of TNC was to ensure interoperability and compatibility with a multitude of standards-based network infrastructure solutions, as well as choice by providing open standards for NAC implementation. Figure 1 shows a comparison of key aspects of the three NAC architectures.



By 2005, these three architectures - two proprietary and one open industry standard - were clearly defined; products were shipping based on the Cisco and TNC architectures, and security administrators could choose which were most appropriate to meet their requirements. In 2006, Microsoft and Cisco cross-licensed their NAC and NAP protocols to enable the two frameworks to interoperate in a shared network environment.

As a member of TCG, Microsoft joined forces with TNC to enable interoperability between TNC and NAP; in April of 2007, TNC published an interface specification that allows either the use of Microsoft SOH or the TNC health checks. Microsoft shipped its first NAP architecture-based products, Windows Server 2008 and Vista / XP SP3, in 2008. Now, endpoints running a TNC Client or a Microsoft NAP Agent can communicate with a TNC PDP or a Microsoft NPS.

Current TNC standards extend NAC beyond the original three-element endpoint / network device / policy server model to include other security devices such as network Intrusion Prevention Systems (IPS), vulnerability scanners, and more, via a Metadata Access Point (MAP) that acts as a clearinghouse for information. In addition to the location, identity, and health considerations enabled by the original TNC architecture, this adds a behavioral factor to policy decisions.

Current Status of NAC Standards Efforts

While Microsoft and TNC are interoperable via open standards today, Cisco is not - yet. However, the Internet Engineering Task Force (IETF) has created a Network Endpoint Assessment (NEA) Working Group with the goal of universal agreement on NAC protocols, and Cisco participates in that effort.

In March of 2006, IETF held a “Birds of a Feather” meeting (BOF) to discuss establishment of a working group for network endpoint assessment. With the interest confirmed, the NEA WG was chartered in October 2006, co-chaired by a Cisco engineer and one of the TNC WG chairs. In the fall of 2008, NEA reached consensus to use two TNC protocols as the basis for development of its first two specifications: PA-TNC: A Posture Attribute Protocol (PA) and PB-TNC: A Posture Broker Protocol (PB). A Cisco engineer is a co-editor, along with the original TNC editors, on each of these specifications.

Through a typical IETF process, each specification is discussed on the working group email list and at IETF meetings for periodic changes to the protocol as it progresses towards becoming a standard. As a result, the IETF specification will not be identical to the original TNC interface when it is finally published. However, TNC has committed to make its protocols compatible when the IETF standard is finalized and approved, providing an open, interoperable NAC roadmap to the future.

The IETF specification discussion is open to anyone with an email address. This provides an extensive amount of feedback but also can mean that issues take a long time to resolve. In 2009, IETF is working on the first two protocols. Currently, TNC has published seven interfaces, so it will take time before the IETF standard addresses a similar set of functionality. The first two protocols will not completely standardize the endpoint integrity communications, so universal agreement on NAC protocols is still a goal for the future. All major vendors except Cisco have agreed on the TNC standards today, but full convergence will not be achieved until the IETF specs are completed. Fortunately, Cisco switches and wireless access points are fully compatible with the TNC specifications so those specifications provide broad compatibility.

Choosing a NAC Solution Today

IT departments implementing NAC today are turning to TNC for several reasons. TNC is a mature architecture with product implementations - such as Juniper's Unified Access Control (UAC) - available and tested in the field for several years. TNC standards will keep pace with IETF NEA's work, and the implementers will keep pace with the TNC revisions.

The open standards from TNC ensure interoperability, reducing vendor lock-in concerns, and ensuring flexibility for deployment and integration of additional network security devices. For IT