IETF pushes for interoperable NAC

Network access control has come to refer to technology that enables enterprises to enforce security policies on endpoints connected to their networks. An enterprise security policy, for example, might require endpoints to have up-to-date security patches and antivirus tools, or prevent the use of applications such as peer-to-peer file sharing or instant messaging.

NAC endpoint security policies can be verified only by scanning the endpoint for compliance from the inside. This process involves taking measurements on the endpoint, such as file versions or checksums, and comparing them against reference values. But to keep up with antivirus vendors updating their signatures, or operating system vendors issuing new security patches, the database of reference values can change almost daily. Clearly, a certain amount of infrastructure is needed to support all of these NAC moving parts.

Mapping NAC solutions to the IETF's Network Endpoint Assessment model.
NEAMicrosoft: Network Access ProtectionTrusted Computing Group: Trusted Network ConnectCisco: Network Admission Control
Posture Attribute (PA)Statement of Health (SoH)Integrity Measurement (IM)Posture Token
Posture CollectorSystem Health Agent (SHA)Integrity Measurement Collector (IMC)

Posture

Plug-in
Posture Broker ClientNAP AgentTNC ClientPosture Agent
Posture Transport ClientNAP Enforcement ClientNetwork Access RequestorEndpoint Device
 NAP Enforcement ServerPolicy Enforcement Point (PEP)Network Access Device (NAD)
PA Protocol IF-M 
PB Protocol IF-TNCCS 
PT Protocol IF-TEAP
Posture Transport ServerNetwork Policy Server (NPS)Network Access Authority (NAA)Access Control Server (ACS)
Posture Broker ServerNAP Administration ServerTNC ServerPosture Server
Posture ValidatorSystem Health Verifier (SHV)Integrity Measurement Verifier (IMV)Posture Validation Server (PVS)

Multiple vendors offer what appear to be comparable NAC solutions, but none are interoperable. This makes NAC a strong candidate for standardization. Last fall, the IETF chartered the Network Endpoint Assessment (NEA) Working Group to standardize the protocols common to a number of NAC infrastructure architectures, such as Network Access Protection from Microsoft, Cisco Network Admission Control and Trusted Network Connect from the Trusted Computing Group, with the goal of promoting interoperability.

Initially, the priority would be standardizing the protocols that carry information about the status of various endpoint attributes - what the NEA calls "posture attributes" - between "collectors" on clients and the "validators" that run on policy servers.

The NEA tasked a subgroup to put together a first draft of the requirements document, and this draft was circulated on a mailing list in January. It included proposed terminology, use cases and a reference model, with requirements for specific protocols to be standardized (see graphic).

The reference model includes posture collectors and posture validators for specific policy components, such as a particular vendor's antivirus tool. A posture collector assembles posture attribute (PA) values that its corresponding posture validator knows how to evaluate. The posture broker client and server multiplex messages exchanged between collector-validator pairs. The posture transport client and server establish a communications channel between the endpoint (NEA client) and policy server (NEA server).

(A table aligning elements of the proprietary architectures with the NEA terminology is at www.nwdocfinder.com/7839.)

The NEA charter proposes to standardize the PA protocol that carries component-specific attributes end-to-end between collectors and validators, and the posture broker (PB) protocol that carries aggregate PA messages end-to-end. In addition, it will lay down requirements for suitable posture transport protocols that carry PB messages between the NEA client and NEA server.

Note that other capabilities and protocols that might affect interoperability are conspicuously out of the scope of the current NEA effort. Most notable are those dealing with enforcement or remediation.

Also, NEA proposes only to standardize "infrastructure" NAC protocols, while there are many vendor offerings that deviate significantly from this model. For example, NAP IPSec enforcement, which uses X.509 public-key certificates obtained by the client submitting its statement of health to a health-registration authority server, and then later using the health certificate to establish IPSec security associations with peer servers.

NEA, now in its early stages, should be considered a work in progress, a time traditionally prone to controversy when multiple viewpoints and constituencies emerge. Lately, these discussion topics have included scope and goals, whether certain use cases are in or out of scope and privacy concerns in the presence of invasive enterprise client software whose goal is to scan attaching endpoints.

However, participants remain hopeful that NEA will complete its initial work program on schedule, which is an approved requirements informational RFC by December.

Tardo is chief security architect of Nevis Networks.

Learn more about this topic

Opinion: An educated guess as to why NAC schemes abound

04/03/06

Cisco, Microsoft effort called a small step for NAC

09/18/06

End-to-end NAC remains difficult

05/01/06

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2007 IDG Communications, Inc.

SD-WAN buyers guide: Key questions to ask vendors (and yourself)