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)
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.
Related documents from the TNC that might be interesting:
Additional information is available at tools.ietf.org/wg/nea
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.
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.
(You may also be interested in the 2007 Vendor White Papers.)
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.
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
What are your EAP Authentication Options?
802.1X Inner Authentication Methods
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