Many WLAN owners know that 802.1X makes it possible to authenticate wireless users. But did you know that 802.1X can also be used to funnel wireless traffic onto Virtual LANs that reflect user or group permissions? In this tip, we explore how to establish this critical link between authentication and authorization.
Tagging wireless traffic
As described in the tip, Using VLANs to compartmentalize WLAN traffic, Ethernet packets can be divided into logical groups using 802.1Q tags. Packets are tagged as they enter a LAN so that upstream devices (e.g., gateways, routers, firewalls) can apply security and QoS filters. For example, Access Points may tag wireless traffic so that it can remain segregated from wired traffic as it moves through the network, from AP to edge switch, to core switch to Internet router.
In our previous tip, we discussed how tags are applied and filtered by wired devices, and best practices associated with VLAN configuration. But how can your APs decide which VLAN tags to apply to which packets?
- To apply the same security and QoS policies to all traffic entering your network over wireless, configure all of your APs or edge switches to assign a single tag. This option is viable only for small, special-purpose WLANs, like visitor Internet access WLANs.
- To divide wireless users into groups based on Extended Service Set Identifier, configure all APs to map SSIDs to unique VLAN tags (e.g., all packets arriving from stations connected to SSID "employee" receive tag #1, while those arriving from SSID "administrator" receive tag #2). This method is common, but vulnerable to VLAN hopping. In this example, users could evade filters associated with VLAN #1 by connecting to the "administrator" SSID, placing themselves into VLAN #2.
- To avoid VLAN hopping, have your 802.1X RADIUS server return a list of permissible SSIDs for each authenticated user. For example, when Joe Admin authenticates using 802.1X, the Access Accept message can carry attributes that permit him to use either "employee" or "administrator" SSIDs. But when Jane Doe tries to use the "administrator" SSID, the Accept message indicates that she is only permitted to use the "employee" SSID. The AP to which Jane has associated will disconnect her before she can send any data. This method supports static VLANs with the same authorization granularity but stronger access control.
- To apply your existing wired network VLANs to stations that connect over wireless, tags must be applied dynamically based on user or group identity. This can be accomplished by having your 802.1X RADIUS server return a tag for each successfully-authenticated user. For example, suppose that your wired network is divided into organizational VLANs -- tag #1 for management, tag #2 for accounting, tag #3 for engineering and tag #4 for human resources. Ethernet switch and firewall filters already exist to stop engineering traffic from reaching accounting databases. To extend those controls to users connecting over wireless, configure your RADIUS server to return tag #3 whenever anyone from engineering authenticates via 802.1X. And so on. This method centralizes VLAN assignment in your RADIUS server, instead of requiring tags to be configured into each AP. It reduces administrative effort and error, and lets you decouple SSIDs and tags, should you wish to use SSIDs for another purpose (e.g., 802.11n migration, segregating voice and video).
How to use RADIUS for VLAN assignment
RFC 3580 specifies guidelines for using 802.1X with Remote Authentication Dial In User Service (RADIUS). These guidelines explain how to map RADIUS attributes to corresponding 802.1X protocol fields, including termination reasons, station and AP identifiers, timeouts and vendor-specific attributes. In particular, RFC 3580 describes how RADIUS servers can use the following tunneled attributes to return VLAN tags within Access Accept messages where VLANID is an integer between 1 and 4094, encoded as a string:
Tunnel-Type=VLAN (13)
Tunnel-Medium-Type=802
Tunnel-Private-Group-ID=VLANID
Your RADIUS server and all APs must either support this RFC-defined mapping or the same proprietary vendor-specific attributes.
To use this method, you must configure your AP to accept VLAN tag values from your RADIUS server and apply them to traffic. Depending on your AP, this may be done through global AP parameters or "RADIUS profiles" that apply to individual radios or SSIDs. For example, you might apply one RADIUS profile to all SSIDs using WPA or WPA2-Enterprise, while applying static VLAN tags to other SSIDs that do not use 802.1X (e.g., visitor WLANs). When configuring VLANs, it is recommended that a separate VLAN be used for AP administration.
You will also need to configure your RADIUS server with users or groups, and the VLAN tags that you wish to associate with them. The RADIUS server may itself consult another authentication server, like a Domain Controller, to verify user credentials. For example, a Domain Controller may return an authenticated user's group affiliation, which the RADIUS server will use to find the right tag to pass back to the AP as the Tunnel-Private-Group-ID attribute.
In fact, most Network Access Control (NAC) architectures can now use RADIUS to return VLAN tags to 802.1X-capable endpoints after user authentication and endpoint assessment. One common policy is returning a different VLAN tag to any authenticated user that fails endpoint security assessment, thereby isolating it on a "quarantine" segment. Once that endpoint has been remediated -- for example, by downloading missing security patches or running a virus clean-up script -- it may reset its wireless connection, triggering 802.1X. On this second pass, RADIUS returns a different VLAN tag to the authenticated, clean, compliant endpoint, thereby granting access to all network resources appropriate for that user.
Note that VLAN-capable upstream devices are also required, including the Ethernet switch connected to your APs, the RADIUS server itself and probably a DHCP server to hand out IP addresses to wireless stations. The APs and RADIUS server can exchange untagged packets or (preferably) use their own VLAN. The DHCP server(s) must participate in all active VLANs to respond to DHCP requests from stations in each VLAN.
Finally, whether you map your entire WLAN to one VLAN, or assign users to different VLANs via 802.1X, Access Control Lists are still required to enforce security or QoS policies. VLAN tags let upstream devices apply different policies to LAN packets arriving over the same physical interface (trunk). But defining those policies and deciding where to apply them is still up to you.
>> Read the next tip: Defeating Evil Twin attacks
