Heavy Networking 608: Everything You Ever Wanted To Know About NAC (And Then Some)

Network Admission Control (also called Network Access Control), or NAC, is our topic today. Roughly stated, NAC is about whether to allow a wired or wireless “thing” (a user, a device) onto your network. And if you do allow them, what will they be able to access? If you’ve worked with 802.1X, Cisco ISE, Aruba ClearPass, RADIUS, etc., you’re in the world of NAC. Our guest is Arne Bier. Arne’s a Senior Consulting Engineer and CCIE who emailed us asking to have this NAC conversation. We hit a bunch of topics including MAC authentication bypass, client certificates, EAP methods, and more. We also discuss reasons why NAC is worth deploying despite the effort. By the way, maybe you’re an independent engineer with something you’d like to discuss on a future Heavy Networking podcast. Hit our contact form at packetpushers.net, or email [email protected]. We’d love to hear from you and consider your topic. Sponsor: NS1 NS1 delivers DNS, DHCP, IPAM, and traffic steering as a service for your applications on premises and in the cloud. Find out more at ns1.com/packetpushers. Show Links: 802.1X Authentication Services Configuration Guide, Cisco IOS XE Release 3SE (Catalyst 3850 Switches) – Cisco Cisco ISE Secure Wired Access Prescriptive Deployment Guide – Cisco Show Outline: Why NAC? * BTW: NAC can also mean Device Administration (TACACS+/RADIUS) but we are discussing end-client NAC today – in particular wired and wireless endpoints * No. 1 reason: Security Compliance (company mandate or even industry regulations – PCI/HIPAA etc) * Visibility (what’s connecting to my network at any one time) * Enabler for dynamic authorization – e.g. quarantine a compromised device * Config consistency and Plug&Play simplicity (esp on Switch ports) Common NAT Hot Topics At The Start Of A Project: * Most customers don’t know what is in their environment and struggle to create an all-encompassing policy that describes WHAT is allowed to connect, and HOW to treat each device * Certificate based authentication is the gold standard (EAP-TLS) * 802.1X requires client certificates (common misconception and reason to not implement 802.1X) * Server certificate and Client Certificates often mixed up – which one is used for what and when? * Which CA should I use to sign the EAP certificate? * 802.1X is too complicated – let’s just do MAB! We’ll discuss MAB later Technical Explanation Of The 802.1X “Ingredients” Required * IEEE standard – Layer 2 authentication method * Uses the EAP framework (IETF) – defined in RFCs * EAP carried over Layer 3 using RADIUS (SP’s also use DIAMETER) * RADIUS is not secure – RADSec solution – TLS tunnel * Supplicant (client) – Windows 7 and later, MACOS, iOS, Android, Linux, and many others * Authenticator (Switch/WLC) – Most Enterprise Class Switches will have this * Authenticating server (RADIUS) – Cisco ISE, Aruba Clearpass, Microsoft NPS, Juniper SBR (Steel-Belted RADIUS), Free RADIUS * EAP Methods: e.g. EAP-PEAP, EAP-TLS, EAP-SIM – pros and cons of each * Identity Sources: AD, LDAP, ODBC, Internal Users (internal to the RADIUS platform) – not all support MS-CHAPv2