Network Admission Control (NAC)
NAC operation

NAC implementation combines a number of existing protocols and Cisco products with some new products and features, including the following:

  • Cisco Trust Agent (CTA) and plug-ins
  • Cisco IOS Network Access Device (NAD)
  • Extensible Authentication Protocol (EAP)
  • Cisco Secure Access Control Server (ACS)/Remote Authentication Dial-In User Service (RADIUS)
  • Posture validation/remediation server

CTA communicates with other software on the client computer over a published Application Program Interface (API) and answers posture queries from the NAD. CTA also implements the communication necessary to implement NAC using EAP over UDP. The resident software includes a Posture Plug-In (PP) that interfaces with the CTA. The PP is an agent included with third-party software that reports on the policy and state of this software.

In the current implementation of NAC, the NAD is a Layer 3 Cisco IOS software device that queries client machines seeking network access using EAP over UDP (EOU). The way that the different components of the NAC solution interact is shown in Figure .

NAC Component Interaction
NAC component interaction occurs as follows:

  1. Client sends a packet through a NAC-enabled router.
  2. NAD begins posture validation using EOU.
  3. Client sends posture credentials using EOU to the NAD.
  4. NAD sends posture to Cisco ACS using RADIUS.
  5. Cisco Secure ACS requests posture validation using the Host Credential Authorization Protocol (HCAP) inside an HTTPS tunnel.
  6. Posture validation/remediation server sends validation response of pass, fail, quarantine, and so on.
  7. To permit or deny network access, Cisco Secure ACS sends an accept with ACLs/URL redirect.
  8. NAD forwards posture response to client.
  9. Client is granted or denied access, redirected, or contained.

When the client sends a request for network access (1), the NAD starts the posture validation process (2). The identity it receives from the CTA is passed on to Cisco Secure ACS, which then initiates a protected EAP (PEAP) session with the CTA (the PEAP session is not shown).

CTA then sends its credential with any credentials it gets from PPs on the client machine to the NAD (3), which forwards them using the RADIUS protocol to Cisco Secure ACS (4). These credentials contain attributes that hold information about the current state of the client software.

Cisco Secure ACS checks and validates the credentials by comparing the attributes contained in the credentials against its policy database. Cisco Secure ACS can also be configured to pass these credentials and attributes to an external server for validation (5). This is done using HCAP over an HTTPS tunnel. This may be the preferred option when client software comes with a PP and an external posture validation server for credential evaluation.

Where there is an external posture validation server, the external server checks the credentials and attributes against its internal database and returns an application posture token (APT) to Cisco Secure ACS. Cisco Secure ACS then collects all APTs from any local or external policies. The most restrictive of these APTs becomes the system posture token (SPT).

Cisco Secure ACS then places the client in a group corresponding to its SPT. These groups correspond to the access rights granted by the SPT and may be Healthy, Checkup, Quarantine, Infected, or Unknown. Cisco Secure ACS then sends the appropriate ACL for the group to the NAD to be applied against the client (8).

Cisco Secure ACS can optionally include an HTTP redirect in the returned policy sent to the NAD to force a client to visit a particular server for a mandatory update and to determine if remediation has occurred.

A posture agent can be developed to return information contained in its credential by the CTA that can be used in many ways, including assessment for host intrusion detection system (HIDS), host intrusion prevention system (HIPS), personal firewalls, operating system patch levels, and application version control.