Port Based Authentication (Dot1x auth)

Most of my study time the last few days has been devoted to Port Authentication using dot1x (802.1x). Going to my BCMSN book was honestly not a lot of help since it appears the CCNP only requires you to know how to set up the simplest authentication, only for wired, and only the switch commands. I will cover, perhaps a bit more than the switching exam expects you to know, but it is an involved process so it will still be an overview.

Why do you need port authentication? Well suppose someone brings in a laptop from home full of virus', or a malicious user decides to unplug a work computer and use the network cable to plug in their own laptop to attack your network. (I know everyone has perfect, aware, tech savy, completely trusted employees and users, but this is just theoretical)


Step one is to have policies and procedures in place. Do you want to allow users to bring in their own laptops? Use your wireless? Use your wired? Can they take work laptops home or to coffee shops? Do you make them a part of your domain so you can push updates, packages, and policies. Will you quarantine them when they return to scan for viruses, get the latest updates, etc? Do you have training to make your users aware of potential pitfalls? Can they recognize unsafe attachments, links, or files? This is just the beginning of all the things you need to plan ahead for, but as you can see they can influence your technical solutions so do some administrative planning, paperwork, and all the boring stuff before you start out to secure your network or you will have some serious project scope issues later on. (If you are choosing to pursue the CCNA security you will have several chapters worth of standards, policies, procedures, and the like to think on)

Ok, so you decide you do not want home or outside computers on your wired network (smart plan). Apart from locking every network jack and PC in cabinets to make it impossible to unplug and use the network cable, you are going to need to limit what clients can connect to your switch.

Option 1. Port security, use sticky macs (unless you want to manually type every mac address) so when turned on, the switch will learn (configurable) one mac address. Then if you unplug and try to swap the computer and a second mac address is seen on the switch port, the port is shut down. To get around this, users spoof the allowed computer's mac address.

Option 2. IPSEC - This method I am still researching and know little about it, but perhaps I can do an update later. In general, this method authenticates each packet sent, eliminating the possibility of spoofing macs or man in the middle attacks that I can explain later.

Option 3. 802.1x Port Authentication - When a computer is connected to a switch port (or wireless), it must authenticate before it is allowed to send any regular packets. Both host and switch must support 802.1x authentication. I can now skim over this LAYER 2 technology.

802.1x always refers to the parties involved as the supplicant (client device or PC), authenticator (switch or network device) and the authentication server (Radius server).

Authentication is managed with EAPOL (extensible authentication protocol over LANs) packets. No other packets are allowed before authentication except EAPOL, meaning no DHCP, no DNS, nothing. Either the switch or the client can initiate the authentication, and it is ended by either logging the user out of the computer, shutting the port down, or timing out the authentication on the switch.

Authentication can be handled with local usernames/passwords (but if you have more than 5-10 employees this would get out of hand) or more commonly with a RADIUS server. The authentication request is made by the user or switch. The computer responds with either a certificate or username/password credentials, whichever is configured. The exact process:

1. Authenticator requests identity of supplicant (since this is the terminology you will see on the test)
2. Supplicant responds with an identity (username)
3. Authenticator receives and passes on access request and identity to auth server (RADIUS)
4. Auth server responds with challenge (password request) to Authenticator
5. Authenticator challenges supplicant
6. Supplicant sends challenge response (password) to Authenticator
7. Authenticator sends challenge response to Auth Server
8. Auth server responds with Accept or Reject to Authenticator
9. Authenticator sends EAP success or starts process over with supplicant

The switch has three states to apply dot1x to each interface
1. force-authorized - any client will be allowed to pass traffic whether they can pass authentication or not. (this is the default to prevent service interruption while deploying dot1x)
2. force-unauthorized - Never allow any client to pass traffic whether they can pass authentication or not. (I don't know why you would ever use this, leave a comment if you know why you wouldn't just shut down the port)
3. auto - Port performs the 802.1x exchange and if successful, moves the port from un-authorized to authorized states. This is the only state that actually performs the authentication exchange.

The radius server can, if you configure it, tell the switch, based on what user, what computer, what switch, what time of day, etc. what vlan to put the computer in, or even send individual user ACLs that limit or permit them to resources based on the current situation. In the CCNA and CCNP tests you just need the RADIUS server to accept or deny the device/user credentials, and it will allow the user to communicate on that port and access vlan.

So, first you need a running radius server. Microsoft, FreeRADIUS on Linux, or Cisco likes to push it's products by using Cisco ACS in all it's practice labs. (ACS (access control server) is cisco's radius/tacacs server.) The radius server needs to identify the authenticator (the switch), and it likely needs to connect to active directory to authenticate the user and/or computer. The configuration for the RADIUS server is outside of our scope, but you do need to know what ports it is communicating on, older or more recent specifications. We can set these ports later on.

Now for the switch config

First don't forget, this is authentication, so you are going to need aaa turned on.

aaa new-model

Next you need to define your radius servers. (perform this command for each radius server)

radius-server host [ip-address] auth-port [port#] acct-port [port#] key [RadiusKey]

Next you tell dot1x to use the whole group of radius servers.

aaa authentication dot1x default group radius

Now we get to enable dot1x on the switch. (all ports start in default state of force-authorized so no one will be blocked yet)

dot1x system-auth-control

Now that dot1x is actually running on our switch (I mean Authenticator) you need to choose any ports that you want dot1x to actually run on, and change the state to auto.

interface [type num/range]
dot1x port-control auto

If you have some ports with a hub/non managed switch or other reasons for having multiple computers connected, you can run multi host mode

interface [type num/range]
dot1x host-mode multi-host


The largest security risk with 802.1x is a man in the middle attack. If a malicious user comes along with a hub, unplugs the work computer (compA) and plugs in the hub, then runs a patch cable to both compA and his own laptop (lapB), the switch doesn't know the difference. It will request authentication from compA, who responds correctly, and the port is now authenticated and able to pass traffic meaning the laptop can also pass traffic. This is why many people suggest using both 802.1x and a per packet IPSEC security method.


If you were interested in the "quarantining out of compliance computers to force them to update" then you would be wanting to use dot1x to have two vlans, and un-authorized vlan and an authorized vlan. Then, cisco's clean access server, microsoft's NAP (network access protection) or other third party remediation server would be part of the authentication process. If the client does not pass authentication and the compliance level for updates, anti virus, etc., then they are left in an un-authorized vlan which only has access to, say, a wsus server, antivirus install server, and/or an image server so that they can "clean up their act" before attempting to re-authenticate.