eduroam e 802.1X: Autenticação WiFi Segura para o Ensino Superior

PODCAST SCRIPT: eduroam and 802.1X — Secure WiFi Authentication for Higher Education Runtime: approximately 10 minutes Voice: UK English, male, senior consultant tone — confident, conversational, authoritative --- [INTRO — 1 minute] Welcome back. I'm going to spend the next ten minutes walking you through eduroam and 802.1X — what they are, how they actually work under the hood, and what your team needs to know before you deploy or integrate with either. If you're an IT manager, network architect, or CTO at a university, college, or research institution — or if you're a venue operator who needs to understand what your academic visitors are expecting from your wireless infrastructure — this is the briefing for you. Let's start with the big picture. eduroam stands for "education roaming." It's a global WiFi roaming service that lets students, researchers, and staff from member institutions connect to the internet at any participating venue — automatically, securely, using their home institution's credentials. No guest portals. No voucher codes. No asking the front desk for a password. It's been running since 2003, it now covers over 10,000 institutions across more than 100 countries, and it is the de facto standard for campus wireless networking in higher education worldwide. If your organisation intersects with universities — whether you're a hotel near a campus, a conference centre hosting academic events, or a public library in a university town — understanding eduroam is directly relevant to your network strategy. --- [TECHNICAL DEEP-DIVE — 5 minutes] Right. Let's get into the mechanics. eduroam is built on top of IEEE 802.1X — the port-based network access control standard. 802.1X defines a framework for authenticating devices before they're granted access to a network. It was originally designed for wired Ethernet but it maps cleanly onto wireless, and it's the foundation of what we call WPA2-Enterprise or WPA3-Enterprise security. The 802.1X model has three components. First, the Supplicant — that's the device trying to connect. A student's laptop, a researcher's phone. Second, the Authenticator — that's your network access point or managed switch. It sits between the supplicant and the rest of the network and acts as a gatekeeper. Third, the Authentication Server — almost always a RADIUS server. RADIUS stands for Remote Authentication Dial-In User Service. It's the component that actually validates the credentials. Here's how the handshake works. The student's device associates with the wireless access point. The access point doesn't grant full network access yet — it opens what's called a controlled port, but only for EAP traffic. EAP is the Extensible Authentication Protocol. The access point proxies the EAP conversation between the device and the RADIUS server. The RADIUS server challenges the device, the device responds with credentials — typically a username and password, or a certificate — and if the RADIUS server is satisfied, it sends back an Access-Accept message. The access point then opens the full network port. The whole exchange takes under two seconds in a well-configured deployment. Now, where does eduroam layer on top of this? eduroam uses a hierarchical RADIUS proxy infrastructure. Each participating institution runs its own RADIUS server — called the Identity Provider, or IdP. When a student from, say, the University of Manchester visits Imperial College London and connects to the eduroam SSID, their device sends their credentials in the format username@manchester.ac.uk. Imperial's RADIUS server sees the realm — that's the part after the @ symbol — and proxies the authentication request up to the national RADIUS server, which is operated in the UK by Jisc, the national research and education network. Jisc then routes the request to the University of Manchester's RADIUS server, which validates the credentials and sends back an Accept or Reject. The whole chain resolves in milliseconds. This proxy chain is what makes eduroam work across institutional boundaries without any pre-shared secrets between institutions. Each hop in the chain uses a shared RADIUS secret only with its immediate neighbour. The student's actual password never leaves the home institution's RADIUS server — it's protected end-to-end by the EAP tunnel. Speaking of EAP methods — this is where a lot of deployments go wrong, so pay attention. The most common EAP methods in eduroam are PEAP — Protected EAP — and EAP-TLS. PEAP wraps an inner authentication method, usually MSCHAPv2, inside a TLS tunnel. It requires a server-side certificate on the RADIUS server, but the client only needs a username and password. EAP-TLS is the more secure option — it uses mutual certificate authentication, meaning both the server and the client present certificates. It's harder to deploy at scale because you need a PKI to issue client certificates, but it's essentially immune to credential phishing. The critical security requirement that many institutions get wrong is certificate validation on the client side. When a device connects to eduroam using PEAP, the device must verify the RADIUS server's certificate before submitting credentials. If the device is misconfigured to accept any certificate, an attacker can stand up a rogue access point broadcasting the eduroam SSID, present a self-signed certificate, and harvest credentials. This is a known attack vector. The fix is to configure your supplicant profiles — via MDM for managed devices, or via the eduroam Configuration Assistant Tool, known as CAT, for personal devices — to pin the expected certificate authority and server name. From a standards perspective, eduroam deployments are expected to comply with the eduroam Policy Service Definition, which mandates TLS 1.2 or higher for all RADIUS over TLS connections, prohibits the use of weak EAP methods like EAP-MD5 or LEAP, and requires that all RADIUS proxy connections use RadSec — RADIUS over TLS — rather than plain UDP RADIUS where possible. This aligns with NCSC guidance in the UK and NIST SP 800-120 in the US. One more technical point worth flagging: VLAN assignment. In a well-architected eduroam deployment, the RADIUS Access-Accept response includes VLAN attributes that tell the access point which VLAN to assign the connecting device to. This lets you segment traffic — putting visiting students on a restricted VLAN with internet-only access, while your own staff get routed to the internal network. This is essential for compliance, particularly if you're subject to PCI DSS or need to maintain separation between research data networks and general internet traffic. --- [IMPLEMENTATION RECOMMENDATIONS AND PITFALLS — 2 minutes] Let me give you the practical guidance. If you're deploying eduroam for the first time, your first call should be to your national NREN — in the UK that's Jisc, in Ireland HEAnet, in the US Internet2. They handle federation membership and will assign you a RADIUS realm. You cannot participate in eduroam without being a member of your national federation. Your infrastructure checklist: you need 802.1X-capable access points — any enterprise-grade kit from Cisco, Aruba, Juniper, Ruckus, or Ubiquiti UniFi will do this. You need a RADIUS server — FreeRADIUS is the open-source standard, or you can use Microsoft NPS, Cisco ISE, or Aruba ClearPass. You need a valid TLS certificate for your RADIUS server from a CA that is trusted by the eduroam community — typically a certificate from your institution's PKI or a commercial CA on the eduroam approved list. The three most common deployment failures I see are: first, certificate misconfiguration — either the RADIUS cert has expired, or the client supplicant profiles aren't pinned correctly. Second, RADIUS proxy timeouts — if your upstream NREN connection has latency issues, authentication will time out and users will see connection failures that look like credential errors. Third, VLAN misconfiguration — visiting users end up on the wrong network segment, either getting no internet access or, worse, getting access to internal resources they shouldn't see. On the client side, deploy eduroam CAT profiles to all managed devices via your MDM platform. For personal devices, publish the CAT installer link prominently. This single step eliminates the majority of support tickets. For venues that aren't higher education institutions but want to offer eduroam access — conference centres, hotels, and similar — the process is called eduroam Visitor Access, or eVA. It allows non-member organisations to host the eduroam SSID and proxy authentication to the federation without being full members. It's worth investigating if you regularly host academic conferences or university events. --- [RAPID-FIRE Q&A — 1 minute] Quick questions I get asked regularly. "Can eduroam replace our guest WiFi entirely?" No. eduroam only works for users who have credentials at a member institution. You still need a separate guest WiFi solution for everyone else — visitors, contractors, the general public. "Is eduroam compliant with GDPR?" Yes, with caveats. The federation architecture means your institution processes authentication data, but you need to ensure your privacy notices cover this and that your RADIUS logs are handled appropriately. "Can we use WPA3 with eduroam?" Yes. WPA3-Enterprise is fully compatible with 802.1X and is the recommended standard for new deployments. It adds 192-bit mode encryption for high-security environments. "What's the difference between eduroam and OpenRoaming?" OpenRoaming is a broader industry initiative from the Wireless Broadband Alliance that uses the same 802.1X and RADIUS proxy architecture but extends roaming beyond education to commercial venues. Some platforms, including Purple, support OpenRoaming as part of their guest WiFi offering. --- [SUMMARY AND NEXT STEPS — 1 minute] To wrap up. eduroam is a mature, well-governed, globally deployed WiFi roaming service built on 802.1X and a hierarchical RADIUS proxy infrastructure. It delivers per-user authentication, strong encryption, and seamless roaming across 10,000-plus institutions — without shared passwords or captive portals. For IT teams deploying or upgrading campus wireless: prioritise EAP-TLS over PEAP where your PKI can support it, enforce certificate validation on all client profiles, use RadSec for all RADIUS proxy connections, and segment visiting users into a dedicated VLAN. For venue operators: if you regularly host academic visitors, investigate eduroam Visitor Access. And regardless of whether you deploy eduroam, your guest WiFi infrastructure should be built on enterprise-grade 802.1X principles — not shared PSKs. If you want to go deeper on any of this — RADIUS architecture, PKI design for EAP-TLS, or how platforms like Purple integrate with eduroam and OpenRoaming — the full written guide is linked in the show notes. Thanks for listening. Until next time. --- END OF SCRIPT