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:
- Client sends a packet through a NAC-enabled router.
- NAD begins posture validation using EOU.
- Client sends posture credentials using EOU to the NAD.
- NAD sends posture to Cisco ACS using RADIUS.
- Cisco Secure ACS requests posture validation using the Host Credential
Authorization Protocol (HCAP) inside an HTTPS tunnel.
- Posture validation/remediation server sends validation response of pass,
fail, quarantine, and so on.
- To permit or deny network access, Cisco Secure ACS sends an accept with
ACLs/URL redirect.
- NAD forwards posture response to client.
- 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.