Port-based Network Access Control (PNAC for short) also known as 802.1x is an essential tool in an effective defense-in-depth strategy around securing internal resources on a network thru authentication when used with authentication services such as a Windows Server-based RADIUS Server linked to a Directory Services of usernames and passwords such as Microsoft’s Windows Server Active Directory.
Authentication of a person on a network is your 1st line of defense in knowing the person accessing network resources are who they say they are.
PNAC can be used by a few frameworks for authentication such as: Password Authentication Protocol (PAP), Tunneled Transport Layered Security (TTLS), Microsoft’s Challenged Handshake Authentication Protocol (MS-CHAPv2), and Protected Extensible Authentication Protocol (PEAP), and of the four I’d recommend TTLS and PEAP coupled with MS-CHAPv2.
EAP simply is the facilitator for protocols to attach and encapsulation the EAP message such as EAP-TTLS and EAP-PEAP.
As mentioned above the protocol 802.1X is uses Extensible Authentication Protocol (EAP) and can be used in two fashions:
- EAP encapsulation over LAN (EAPOL) and is used with 802.11 for wireless and other ethernet-based networks such as a traditional LAN with a supplicant being a guest laptop and the authenticator being the switch.
- Typically, EAP is then coupled with a authentication mechanism such as a Windows Server Active-Directory linked RADIUS server (as an example but not limited to Windows) that “authenticates” user access on the network between the authenticator aka “the switch” which validates against the authentication server aka “the RADIUS Server” if the supplicant such as the laptop can access network resources. I’ll explain this in more detail below.
There is three parts to 802.1X: a user or client that wants to be authenticated that is known as a supplicant, the device that is sending the authentication requests known as the authenticator which is typically a access point or a network switch, and finally the server that controls access to the kingdom known as the authentication server which can be either RADIUS/DIAMETER/TACACS+ depending upon vendor and purpose of 802.1X.
This is how it works:
- The supplicant device, lets say a laptop in a conference room, connects to a wall jack, as soon as the link become live the authenticator send a EAP identity request.
- The supplicant then sends a EAP response identity to the authenticator who is then like “ok so you want access”, let me forward this to my boss the “authentication server”.
- The authentication server sends a challenge back to the “authenticator” who then sends the request to the “supplicant” aka the laptop.
- The supplicant responds with login info (either a Active Directory username and password or a certificate as an example – truly depends upon which framework of EAP you are using) and send it’s response to the authenticator and it sends it to the big boss.
- Once the authentication server receives the response from the supplicant with the credentials or validation it seeks the supplicant is then granted access (as authenticated) to the LAN resources. Now if you implement health checking, and the supplicant is missing patches (or doesn’t have login credentials) as an example the supplicant may be granted access to a limited access such as only the internet or remediation network (as unauthenticated) to be ‘updated’ before gaining access to the primary LAN.
As mentioned, all that 802.1X provides is authentication of who you are and who you say you are and if you aren’t this person then your not allowed access to restricted LAN resources that require authentication, plain and simple.
This is why 802.1X is used for wireless, LAN, and Remote Access over VPN as a 1st line authentication for access.
This is as simple as I can explain 802.1X and how it related to a modern network and why you would use it. I think this practice should be coupled with switch port-security, IPSEC and certificate-based access controls but that is for another topic on another day. 🙂