Interop Labs Logo

Interop iLabs NAC Resources

The links below represent output of the Network Access Control (NAC) iLabs team as well as some resources that we felt might be of interest to NAC users and NAC testers.


NAC Topology and Presentations

NAC iLabs Booth Overview (PDF) (PPT) (also from 2006 and 2007: (LV2007 PDF) (LV2007 PPT) (LV2006 PDF) (LV2006 PPT) (NY2006 PDF) (NY2006 PPT) )

NAC terminology glossary and map between IETF, TCG, and Microsoft (PPT)

NAC iLabs addressing topology (XLS) (probably not interesting to most) (LV2007 )

Interop Labs NAC Class Las Vegas 2008 (PDF)   (PPT) (2007 class (PDF)   (PPT)   2006 class (PDF)   (PPT))

Joel Snyder's NAC Day Presentation (Courtesy Opus One)

Interop Labs Team White Papers

Here are the white papers from the 2008 iLabs NAC project. All are PDF files. You may reproduce and distribute these files unchanged.

What is NAC? Generic network access control at its core is a simple concept: Who you are should govern what you're allowed to do on the network. NAC, then, is simply the hardware and software that together let you enforce access control policies based on who you are.

What is 802.1X? Understanding what IEEE 802.1X is, its relationship to NAC, and why you should care about it means understanding three separate concepts: EAP (Extensible Authentication Protocol), IEEE 802.1X itself, and Tunneled Authentication.

Getting Started with Network Access Control If you'd like to implement Network Access Control, no matter what architecture you select, you definitely want to start by building a small interoperability lab. In this white paper, we'll give you some advice on what to think about before you get started, and outline what resources you ll need to have in place in order to begin testing.

What is TCG's Trusted Network Connect? The Trusted Computing Group (TCG) is an industry standards body formed to develop, define, and promote open standards for trusted computing and security technologies. TCG has developed an open architecture and standards for Network Access Control called Trusted Network Connect (TNC).

What is Microsoft's Network Access Protection? The most significant differences between Microsoft's Network Access Protection architecture and other NAC architectures you see in the iLabs come because Microsoft does not make switches or routers. Therefore, the path for handling enforcement is different, focusing on server enforcement and standards-based switch enforcement. The original intent of MS-NAP was not security, but to find and quarantine non-compliant clients in the enterprise LAN. As the interest in NAC has increased, Microsoft has adjusted their architecture to include more enforcement mechanisms, and it's the 802.1x portion of MS-NAP that we tested for interoperability in the iLabs.

What is IETF Network Endpoint Assessment? The Internet Engineering Task Force (IETF) is the ultimate arbiter for Internet protocols. They have standardized dozens of critical protocols like IP, TCP, FTP, HTTP, SMTP, and IPsec. With its many competing and incompatible architectures and standards, Network Access Control is ripe for standardization. Fortunately, the IETF has started a Working Group in this area: the Network Endpoint Assessment (NEA) Working Group.

Switch Features for NAC As an IEEE standard, 802.1X is a critical building block in each of the three major NAC architectures. Before deploying one of the NAC architectures, the first step is to roll out 802.1X. This whitepaper will cover the switch and access point features that support an 802.1X environment.

How to Handle NAC Exceptions The IEEE 802.1X standard gets all of the attention when NAC is discussed because it works well, and consistently, across many networking vendor's hardware. NAC deployments often depend on 802.1X both for authentication of the end-user and as a mechanism to tunnel end-point posture assessment information. IEEE 802.1X is a key strategy for interoperable and standards-based NAC deployments. Most network engineers understand that some devices can't be full NAC clients with 802.1X support, but what is surprising is that dealing with these "NAC Exception" devices will consume a disproportionate amount of time. The 20% of devices that can't run 802.1X may end up burning 80% of your design and deployment time.

Merging NAC Strategies of Microsoft and TCG/TNC The most significant event in the evolution of NAC occurred in May, 2007, when the Trusted Computing Group's Trusted Network Connect (TCG/TNC) working group and Microsoft's Network Access Protection (NAP) team effectively merged their work into a single set of compatible standards. This is important for the NAC world because it brings the Microsoft NAP client into an open, standards-based framework that will allow other network and security vendors to build on the infrastructure within the Windows Operating system. Microsoft's NAP client was included in Microsoft Vista and Windows Server 2008, and will be added to Windows XP when Service Pack 3 is released.

Access Controls in NAC To build a NAC solution, you have to bring together three specific security components under a common management umbrella. One of these is enforcement: making sure the user does, in fact, only go where they have permission to based on NAC policy. A spectrum of choices exists in access control methods, ranging from a simple "go/no-go" type of control up to full stateful firewall rule sets. In the middle are the two most commonly used access control techniques: VLAN segregation and packet filtering access control lists (ACLs). This white paper examines these two strategies.

Making NAC Security-Aware with IF-MAP At Interop Las Vegas 2008, the Trusted Computing Group introduced a new protocol, IF-MAP. The IF-MAP protocol creates a structured way to store, correlate, and retrieve identity, access control, and security posture information about users and devices on a network. Products that implement this new protocol can become more network and security-aware, in a standardized and interoperable way. IF-MAP can be used to solve many architectural problems with current NAC solutions, and offers applicability far beyond the world of NAC.

Network Access Control Resources This white paper provides pointers to some resources that we've found helpful in our research on Network Access Control (NAC) architectures and interoperability.

TCG/TNC Specifications

The Trusted Network Connect (TNC) Work Group has defined and released an open architecture and a growing set of standards for endpoint integrity. The TNC architecture enables network operators to enforce policies regarding endpoint integrity at or after network connection. The standards ensure multi-vendor interoperability across a wide variety of endpoints, network technologies, and policies.

TNC Architectural Documents

TCG TNC Architecture Version 1.3 (also available V1.2, V1.1 and V1.0)

IF-MAP (Metadata Access Point) Specifications

TNC IF-MAP binding for SOAP Version 1.0
FAQ on IF-MAP Metadata Access Point

Integrity Measurement and Validation Specifications

TCG TNC IF-IMC Specification Version 1.2 (C and Java headers)
TCG TNC IF-IMV Specification Version 1.2 (C and Java headers)

TNC Client to TNC Server Specifications

TCG TNC IF-TNCCS Specification ("Native" TNC) Version 1.1
TCG TNC IF-TNCCS: Protocol Bindings for SoH (Microsoft NAP) Version 1.0
TNC and Microsoft NAP interoperability FAQ
TCG TNC IF-TNCCS TLV Specification ("Native" TNC), proposed V2.0, not ratified
TCG TNC IF-M TLV Binding Specification proposed v1.0, not ratified
TCG IF-M Security: Bindings to CMS Specification proposed v1.0, not ratified
(FAQ on these not-yet-ratified documents)

Authentication and Policy Communication Specifications

TCG TNC IF-PEP: Protocol Bindings for RADIUS Version 1.1
TCG TNC IF-T: Protocol Bindings for Tunneled EAP Methods Version 1.1

Related documents from the TNC that might be interesting:

TNC Specifications FAQ

IETF Specifications

Network Endpoint Assessment (NEA) architectures have been implemented in the industry to assess the "posture" of endpoint devices for the purposes of monitoring compliance to an organization's posture policy and optionally restricting access until the endpoint has been updated to satisfy the posture requirements. An endpoint that does not comply with posture policy may be vulnerable to a number of known threats that may exist on the network. The intent of NEA is to facilitate corrective actions to address these known vulnerabilities before a host is exposed to potential attack. Note that an endpoint that is deemed compliant may still be vulnerable to threats that may exist on the network. The network may thus continue to be exposed to such threats as well as the range of other threats not addressed by maintaining endpoint compliance.

Additional information is available at

Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge that software installed to protect the machine (e.g. patch management software, anti-virus software, host firewall software, host intrusion protection software or any custom software) is enabled and up-to-date. An endpoint supporting NEA protocols can be queried for posture information.

An organization may make a range of policy decisions based on the posture of an endpoint. NEA is not intended to be prescriptive in this regard. Supported deployment scenarios will include, but are not limited to, providing normal access regardless of compliance result along with any recommendations for remediation ("advisory mode"), as well as providing restricted access sufficient for remediation purposes and any essential services until an endpoint is in compliance ("mandatory mode"). Specifying mechanisms for providing restricted access is outside the scope of the NEA WG.

Since NEA involves many different components from different vendors, interoperability is important. The priority of the NEA working group is to develop standard protocols at the higher layers in the architecture: the Posture Attribute protocol (PA) and the Posture Broker protocol (PB). PA and PB will be designed to support a variety of lower layer protocols. When used with standards for lower layers, the PA and PB protocols will allow interoperability between an NEA Client from one vendor and an NEA Server from another.

Since there are already several non-standard protocols at these higher layers, the NEA working group will consider these existing protocols as candidates for the standard protocols. A requirements document will be written and used as a basis for evaluating the candidate protocols. The working group may decide to standardize one of the candidate protocols, use one of them as a basis for a new or revised protocol, or decide that a new protocol is needed.

The NEA Requirements document will include a problem statement, definition of terms, requirements for the PA and PB protocols, and an overall security analysis. It will also include generic requirements for the protocol transporting PA, PB: the Posture Transport protocol (PT). PT protocols may be standardized in other WGs since these protocols may not be specific to NEA. The NEA WG will identify and specify the use of one mandatory to implement PT protocol that is fully documented in an RFC.

The PA (Posture Attribute) protocol consists of posture attributes that are carried between a particular Posture Collector in a NEA client and a particular Posture Validator in a NEA Server. The PA protocol is carried inside the PB protocol. A base set of standard posture attributes will be specified that are expected to address many common posture policies. Vendor-specific attributes will also be supported; vendor-specific attributes will be identified by a private enterprise number and a vendor assigned value. Vendors are strongly encouraged to document vendor-specific attributes in an RFC. The NEA WG will investigate the use of a standard syntax for all attributes.

The PB (Posture Broker) protocol aggregates posture attributes from one or more Posture Collectors in an NEA client and sends them to the NEA server for assessment by one or more Posture Validators.

The PT (Posture Transport) protocol carries the PB protocol.

The NEA working group will not specify protocols other than PA and PB at this time. The expectation is that an existing protocol can be used for the PT.

One commonly discussed issue with NEA systems is how to handle compromised endpoints, whose reports of their own posture may not be accurate. Detecting or handling such endpoints is out of scope of the NEA WG. Work on PA will focus on attributes useful for assessing posture of those endpoints reporting accurate information. However, the protocols developed by the NEA WG must be designed to accommodate emerging technologies for identifying and dealing with lying endpoints.

Note that NEA is not chartered to develop standard protocols for remediation. NEA is intended to be used with new or existing tools that can be used in the absence of NEA. NEA is applicable to computing enterprise environments, where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. All other cases are outside the scope of the NEA charter, since we do not know that NEA would be useful in such cases. NEA applicability and security considerations will be described in the appropriate NEA documents.

IETF Working Documents, RFC, and Drafts

IETF Network Endpoint Assessment draft RFC (June/2006) (also v2   v1   v0 )

Network Endpoint Assessment (NEA): Overview and Requirements (V7, April 2008 version)
This document defines the problem statement, scope and protocol requirements between the components of the NEA (Network Endpoint Assessment) reference model. NEA provides owners of networks (e.g. an enterprise offering remote access) a mechanism to evaluate the posture of a system. This may take place during the request for network access and/or subsequently at any time while connected to the network. The learned posture information can then be applied to a variety of compliance oriented decisions. The posture information is frequently useful for detecting systems that are lacking or have out of date security protective mechanisms such as: anti-virus and host-based firewall software. In order to provide context for the requirements, a reference model and terminology are introduced. (also v6   v5   v4   v3   v2   v1 )

PB-TNC: A Posture Broker Protocol (PB) Compatible with TNC
This document specifies PB-TNC, a Posture Broker Protocol (PB) identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol. The document then evaluates PB-TNC against the requirements defined in the NEA Requirements specification.

PA-TNC: A Posture Attribute Protocol (PA) Compatible with TNC
This document specifies PA-TNC, a Posture Attribute Protocol (PA) identical to the Trusted Computing Group's IF-M 1.0 protocol. The document then evaluates PA-TNC against the requirements defined in the NEA Requirements specification.

Vendor White Papers

These white papers and discussion papers are contributed by vendors and consulting companies who paricipated in the Interop Labs NAC testing this year. As you might expect, we disclaim any responsibility for the opinions that might be expressed in these papers.

(You may also be interested in the 2007 Vendor White Papers.)

Avenda Systems

Enterprise Trust and Identity Policy System Datasheet
Extending Network Access Protection with Avenda's Products
Avenda Linux Network Access Protection (NAP) Agent
Policy Management: The Avenda Approach to an Essential Network Service
Avenda Windows Universal System Health Agent (USHA)

Blue Ridge Networks

NAP Enhanced to Secure Endpoints On and Off the Enterprise

Force10 Networks

Future-proofing the Wiring Closet with Resilient and Scalable Modular Switch/Routers

Great Bay Software, Inc.

Managing the Endpoint Lifecycle with the Beacon Endpoint Profiler


Network Access Control Testing


Network Access Protection Data Sheet
Introduction to Network Access Protection (May 2006 version)

Opus One

Opus One: NAC Deployment: A Five Step Methodology
Opus One: NAC Enforcement Options Pros and Cons

Trusted Computing Group

Trusted Network Connect Press Release on IF-MAP Protocol
Networking Industry and IT Support for TNC and IF-MAP
IF-MAP Product Support
Standardizing Network Access Control: TNC and Microsoft NAP to Interoperate

Configuration Files

As part of the testing we did in the iLabs on NAC, we configured dozens of devices. We tried to capture all the device configurations and we've dumped them into this directory. Rather than write individual links, you should just browse the directory to see if our configurations for Aruba, Avenda, Cisco, Enterasys, Extreme, Force 10, Great Bay, HP, Juniper, NetScreen, Radiator, Trapeze, and Xirrus devices are of any use to you.

We also have the Las Vegas 2007 and 2006 configs, as well as New York 2006 configs available in case that's useful to someone.

External links and Other Resources

Trusted Computing Group Trusted Network Connect home page

Cisco NAC home page

Microsoft Network Access Protection home page
Microsoft NAP API definitions

Internet Engineering Task Force Network Endpoint Assessment (NEA) working group home page
IETF NEA Status Pages

Juniper Networks LAN Access Control home page

Network World research center on NAC
Network World report on Interop Las Vegas 2007 Labs NAC testing results
Network World report on NAC architectures
Network World report on iLabs NAC interoperability testing (2006)
Network World competitive analysis of Cisco and TCG/TNC architectures

802.1X White Papers

802.1X is especially important in wireless LAN security, which was the subject of an Interop Labs initiative in 2003. But 802.1X is equally useful for wired authentication and is used in NAC. Here are the whitepapers from the Wireless LAN Security initiative explaining 802.1X, EAP and authentication methods. And a few other interesting things. These papers range from 2003 to 2005, so may be dated. Please be aware!

What is 802.1X?

What are your EAP Authentication Options?

What is EAP-FAST?

802.1X Inner Authentication Methods

802.11 Alphabet Soup

Network Access Control Taxonomy

Federated Network Authentication with 802.1X

What is Network Policy Enforcement?

Industry Options for Network Access

Open source 802.1X / WPA / WPA2 / 802.11i

802.11 Resources for Wireless Security iLabs LV05

802.11 Resources Diagram

NOC Team Area