Demystifying 802.1X - Part 3 - Authorization and dACLs

Posted: 2014-07-18. Modified: 2022-09-25. Link.

In an ongoing series of blog entries, I've been talking about 802.1X, from the basics to VLAN override as part of an authorization strategy. In this entry I'm going to cover using downloadable access control lists.

Authorization options

VLANs (discussed in a previous blog entry)
Downloadable/Dynamic ACLs
Security Group Tagging

Today I'm going to go through dACLs and compare them to VLANs and how they're a little bit easier (but still not perfect!)

dACLs

dACLs at their core are access control lists which are applied on a session basis, rather than on an interface. This means that they are specific to a user and their current session. They are also typically managed centrally and pushed to a network device automatically.

Let's take the same example as before:

Topology showing Regular Users, HR Directors and Guest Users going across a network to HR Servers, Public Internet and Intranet Services

Corporate Policy

	HR Server 10.10.200.1	Public Services 10.10.210.1	Intranet Services 10.10.220.1
Regular User
HR Director
Guest User

In this case I can configure my ACLs centrally. Here's an example for a regular user:

	deny   ip host 10.10.200.1
	permit ip host 10.10.210.1
	permit ip host 10.10.220.1

Note how the dACL doesn't define the source IP, only the destination? This is automatically populated by the network access device (your switch).

Scaling with dACLs

Unlike VLANs, dACLs don't require toplogy changes for new users. You could even mix different users in the same VLANs and provide different security to each of them. This is an increasingly common approach that I'm seeing where developers may need access to specific subnets that regular employees should not. Rather than complicating matters, a simple DACL pushed permitting them this access saves time and makes topology changes far easier.

dACLs are also centrally managed and pushed out by a RADIUS server. This means that they can be updated much quicker and without changing a network devices running configuration.

Still dependent on Topology

Unfortunately there are still topology dependencies with dACLs. You still need to know the IP addresses of your servers and managing interaction between identity groups becomes very tricky (how would a dACL stop an HR Director and a Regular User from P2P traffic whilst still allowing access to common resources such as printers?).

dACLs represent a good move away from VLANs and I would always consider them as a preferred starting point. VLANs are a neccessary evil in networking, but they shouldn't be the backbone on which we build network security.