continued from page 2

The NAC labyrinth

Rather than try and send Statements of Health around at authentication time, a client proves its health to the Health Certificate Server using normal System Health Agents and Statements of Health. It then receives a digital certificate that it can use instead of normal user credentials for authentication using 802.1X or IPSec. Using certificates in this way is a logical outgrowth of Microsoft's VPN strategy, in which the IPSec authentication is largely irrelevant; instead, the L2TP authentication that Microsoft clients run on top of IPSec is where the user actually proves his identity.

The benefits of this complex system of using Health Certificates are not clear. It's likely the goal is to increase perceived performance by separating out the work of determining system health from actually connecting to network resources. Whether this perception will be worth the increase in complexity and decrease in security is a difficult call to make at this stage in the NAC product life cycle.

Juniper's Infranet

Although it is possible to map the basic components in the Juniper Infranet to TCG's Trusted Network Connect architecture, the reality is that Juniper is trying to accomplish very different things, focusing on firewall and access control, with less emphasis on endpoint security.

A NAC primer

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. When all of the parts are in place, NAC will be a way to apply a policy for network access across LAN, wireless and VPN infrastructures. The access control policy in NAC could range from simple, such as a go/no-go decision on network access or a choice of virtual LANs, or it could be as complex as a set of per-user firewall rules defining which parts of the network are accessible.

Within a NAC deployment, the IT manager uses three main elements to pick an access control policy: authentication, endpoint security assessment and network environmental information.

Authentication is the straightforward "Who are you?" transaction that users are accustomed to with other applications. As a concept, NAC doesn't have any special requirements for authentication. A good NAC deployment would use the same authentication system as other applications. For example, if you're applying NAC to a remote access IPSec VPN tunnel, you should use the same authentication to bring up the IPSec tunnel as you do to authenticate a user.

Endpoint security assessment is the most complex part of selecting a policy in NAC, but it's also the driving factor for deploying NAC in the first place. The underlying idea is that the security posture of the connecting laptop, desktop or server should be a part of access control policies. For example, if a connecting system doesn't have the standard corporate anti-virus package, the user should get a different access control policy than if everything is installed and all the signatures are up-to-date.

Network environmental information is a small but important part of selecting access policies in a NAC scheme. Environmental information might be circumstantial data about whether you're connecting via a wireless network or through a VPN, or whether you're in the building or in another country. These circumstances play into the decision of what access control policy is assigned to the connecting system. For example, if you're coming in on a VPN, you might not be able to get to as many parts of the network as if you were in the building.

NAC is a hot buzzword; therefore, this component-level definition of what NAC is won't map directly to all NAC products and architectures. But most products being offered as part of an overall NAC strategy include at least some component, if not all, of this definition.

Juniper breaks from other vendor's NAC architectures in the amount of control that it gives the network manager when building a NAC infrastructure. Juniper's strategy is very dependent on both authentication and on detailed access control using its firewalls. The result is that when someone enters a network under Juniper's NAC control, every connection goes through a stateful packet filtering firewall, can be encrypted and is explicitly tied to an access control policy based on a user's identity.

For example, when a system enters a network under Microsoft Network Access Protection with DHCP, the main concern is whether the user has the appropriate level of endpoint security. If so, the user is given unlimited access to the network. With Juniper's Infranet, the endpoint security assessment of the user is optional, but the identity-based access control policy is not.

This philosophical difference has one benefit: it makes it easier to decide whether the Juniper approach is right for you, and whether this level of authentication, security and access control is what you're looking for -- or whether you mostly care about endpoint security assessments.

On the client end, Juniper uses its Enterprise Infranet Agent as the focal point for client management. The Infranet Agent links to third-party TCG Integrity Measurement Collectors using its own JEDI API. Juniper also provides endpoint security assessment tools -- a feature of its SSL VPN called Host Checker -- for checking endpoint status, such as open ports or running processes.

Because the user is assumed by Infranet's architecture to already have connected to the network, the Infranet Agent doesn't participate in Layer 2 authentication schemes such as 802.1X. Instead, the Infranet Agent's role is to provide user authentication to the Policy Enforcement Point deeper in the network and the endpoint security assessment information back to the Policy Decision Point, dubbed Infranet Controllers.

Juniper's firewall and SSL VPN products -- called Infranet Enforcers -- act as the Policy Enforcement Points and are typically located deep within the network.

The Infranet Agent also manages encryption between the end system and the Infranet Enforcer Policy Enforcement Point. By applying IPSec encryption between the client and the Infranet Enforcer, Juniper offers strong binding between the end station, its authentication and the applied policy. This security only starts at the Policy Enforcement Point; any misbehavior by the client before it reaches the Infranet Enforcer is uncontrolled in the Juniper Infranet model.

Juniper's Infranet Controllers, akin to the TCG's Policy Decision Points, are based closely on Juniper's SSL VPN product line, as both use the same policy engine.

Unlike other NAC architectures, Juniper's Policy Decision Points don't have a clear link between the Integrity Measurement Verifiers, which evaluate endpoint security information from the Juniper Host Checker (acting as the Integrity Measurement Collector in the TCG scheme) and give a policy decision back to the Infranet Controller. Instead, the Infranet architecture waves away the question of how Integrity Measurement Collectors can pass information to the Integrity Measurement Verifiers within the Policy Decision Point by pointing off to the JEDI specification. In reality, the JEDI specifications are mute on how this link will actually work. This is a weak point in the Infranet architecture because management of desktop and roaming user policy has to be handled once in whatever enterprise console is used to control the third-party security tool and then a second time within the Infranet Controller environment.

Choosing a NAC architecture depends on your goals and your integration strategy. If you're an all-Cisco shop with modern hardware, you can hitch your horse to Cisco's architecture, which is as complete as anyone's. For those interested in standards-based solutions, TCG's TNC is the only real option despite some risk. Microsoft's approach is most appropriate in smaller networks where you want to control the PCs you already own and are most concerned about viruses rather than authentication and access control.

Click here to submit a story for consideration by Cram Session Editor, stories@cramsessionnac.com