Metodi EAP a confronto: PEAP, EAP-TLS, EAP-TTLS e EAP-FAST

Sintesi esecutiva

Per i responsabili IT e gli architetti di rete aziendali, la scelta del giusto metodo EAP (Extensible Authentication Protocol) è una decisione critica che bilancia postura di sicurezza, complessità di implementazione ed esperienza utente. Man mano che le organizzazioni superano le vulnerabili chiavi pre-condivise (PSK) per passare all'autenticazione 802.1X, la scelta si restringe in genere a quattro metodi principali: PEAP, EAP-TLS, EAP-TTLS e EAP-FAST. Questa guida fornisce un confronto tecnico diretto di questi metodi, consentendovi di prendere decisioni architetturali informate per il vostro Guest WiFi e per le reti aziendali interne. Esamineremo le differenze di sicurezza tra i metodi con tunnel basati su password e l'autenticazione reciproca tramite certificati, valuteremo quando i metodi specifici sono appropriati e forniremo indicazioni pratiche per l'implementazione nei moderni ambienti aziendali.

Approfondimento tecnico: Metodi EAP a confronto

PEAP (Protected EAP)

PEAP è ampiamente considerato il cavallo di battaglia aziendale per l'autenticazione 802.1X. Sviluppato congiuntamente da Cisco, Microsoft e RSA Security, crea un tunnel TLS crittografato utilizzando un certificato lato server. All'interno di questo tunnel sicuro, il client si autentica utilizzando un metodo legacy, più comunemente MSCHAPv2.

Il vantaggio principale di PEAP è il suo supporto nativo quasi universale nei moderni sistemi operativi, inclusi Windows, macOS, iOS e Android. Poiché richiede solo un certificato sul server RADIUS e non sui dispositivi client, l'implementazione è notevolmente meno complessa rispetto alle alternative basate su certificati. Ciò rende PEAP estremamente interessante per gli ambienti BYOD (Bring Your Own Device) o per grandi spazi pubblici come gli hub di Trasporti dove la gestione dei certificati client non è pratica.

Tuttavia, l'affidamento di PEAP alle password (tramite MSCHAPv2) introduce rischi per la sicurezza. Se un dispositivo client non è configurato rigorosamente per convalidare il certificato del server, gli utenti possono essere indotti a connettersi a un access point non autorizzato (un attacco "evil twin"). L'AP non autorizzato può quindi catturare la richiesta-risposta MSCHAPv2, che può essere decifrata offline per recuperare la password dell'utente. Pertanto, l'imposizione di una convalida rigorosa del certificato del server tramite Group Policy o MDM è un controllo di sicurezza obbligatorio quando si distribuisce PEAP.

EAP-TLS (EAP-Transport Layer Security)

EAP-TLS rappresenta il gold standard per la sicurezza wireless aziendale. A differenza di PEAP, EAP-TLS richiede l'autenticazione reciproca dei certificati. Sia il server RADIUS che il dispositivo client devono presentare un certificato digitale valido prima che venga concesso qualsiasi accesso alla rete.

Questa autenticazione reciproca elimina completamente la necessità di password, rendendo inefficaci il furto di credenziali, gli attacchi con dizionario e gli attacchi da AP non autorizzati. Se un dispositivo non dispone del certificato client corretto, semplicemente non può connettersi alla rete. Per le organizzazioni soggette a severi requisiti normativi, come PCI DSS nel settore Retail o HIPAA in Sanità , EAP-TLS è l'approccio fortemente raccomandato.

Il compromesso per questa maggiore sicurezza è la complessità di implementazione. L'implementazione di EAP-TLS richiede una solida infrastruttura a chiave pubblica (PKI) per emettere, rinnovare e revocare i certificati. Richiede inoltre una soluzione di Mobile Device Management (MDM), como Microsoft Intune o Jamf, per distribuire in modo sicuro questi certificati agli endpoint. Per indicazioni sugli ambienti Apple, consultate la nostra guida su Jamf e RADIUS: Autenticazione WiFi basata su certificato per flotte di dispositivi Apple . EAP-TLS è la scelta ottimale per flotte di dispositivi gestiti e di proprietà aziendale in cui la sicurezza è fondamentale.

EAP-TTLS (EAP Tunneled TLS)

EAP-TTLS, sviluppato congiuntamente da Funk Software e Certicom, funziona in modo simile a PEAP stabilendo un tunnel TLS crittografato tramite un certificato lato server. Il fattore di differenziazione chiave è la sua flessibilità riguardo al metodo di autenticazione interna. Mentre PEAP è strettamente legato a MSCHAPv2, EAP-TTLS può incapsulare quasi tutti i protocolli di autenticazione, inclusi PAP, CHAP o MSCHAP, in modo sicuro all'interno del tunnel.

Questa flessibilità rende EAP-TTLS estremamente prezioso in ambienti che devono eseguire l'autenticazione rispetto a directory LDAP legacy, proxy RADIUS o archivi di identità non Microsoft che non supportano nativamente MSCHAPv2. È notoriamente il protocollo alla base di eduroam, il servizio di accesso in roaming globale per la comunità internazionale della ricerca e dell'istruzione. Storicamente, il supporto nativo dei client per EAP-TTLS era meno diffuso rispetto a PEAP, richiedendo spesso supplicant di terze parti su versioni precedenti di Windows, ma i moderni sistemi operativi offrono ora un solido supporto nativo.

EAP-FAST (Flexible Authentication via Secure Tunneling)

Sviluppato da Cisco come rapida sostituzione del vulnerabile protocollo LEAP, EAP-FAST è stato progettato per fornire un'autenticazione sicura senza il requisito rigoroso di implementare certificati digitali. Invece di utilizzare un certificato server per stabilire il tunnel sicuro, EAP-FAST si basa sulle Protected Access Credentials (PAC) — blocchi di dati opachi forniti dinamicamente ai client dal server di autenticazione.

EAP-FAST è caratterizzato da rapide capacità di ripresa della sessione. Sebbene fornisca un tunnel sicuro e crittografato, la sua dipendenza dalle PAC anziché dai certificati standard X.509 lo rende in qualche modo proprietario e meno allineato con le moderne architetture zero-trust indipendenti dai fornitori. Oggi, EAP-FAST è rilevante principalmente in ambienti legacy incentrati su Cisco, in specifiche implementazioni IoT o in dispositivi rugged specializzati. Per la maggior parte delle nuove implementazioni aziendali, si preferiscono PEAP o EAP-TLS.

Guida all'implementazione

L'implementazione dell'autenticazione 802.1X richiede un'attenta pianificazione dell'intero stack di rete, dagli access point wireless all'infrastruttura RADIUS e agli identity provider. Durante l'integrazione con la piattaforma di Purple, i nostri server RADIUS supportano tutti i principali metodi EAP, garantendo un'autenticazione fluida prima che gli utenti interagiscano con funzionalità come Wayfinding o WiFi Analytics .

Passaggio 1: Definire la strategia di autenticazione

Valuta la tua flotta di endpoint. Se i dispositivi sono di proprietà aziendale e gestiti tramite MDM, punta a EAP-TLS. Se supporti il BYOD, PEAP è la scelta più pragmatica. Assicurati che il tuo identity provider (Active Directory, Google Workspace, Okta) supporti i protocolli richiesti (ad es. MSCHAPv2 per PEAP).

Passaggio 2: Gestione dei certificati

Per tutti i metodi eccetto EAP-FAST, è necessario distribuire un certificato server sul server RADIUS. Idealmente, questo certificato dovrebbe essere emesso da una Certificate Authority (CA) pubblica attendibile per ridurre al minimo gli avvisi di attendibilità lato client, sebbene sia possibile utilizzare una CA aziendale interna se si controllano tutti gli endpoint. Per EAP-TLS, stabilisci la tua PKI e configura il tuo MDM per fornire automaticamente i certificati client con le corrette mappature Subject Alternative Name (SAN).

Passaggio 3: Configurazione di RADIUS e degli Access Point

Configura i tuoi access point wireless per utilizzare WPA2-Enterprise o WPA3-Enterprise, indirizzandoli agli indirizzi IP del tuo server RADIUS con i segreti condivisi corretti. Sul server RADIUS, definisci i criteri di rete, specificando i metodi EAP consentiti e mappando le autenticazioni andate a buon fine sulle VLAN appropriate in base all'appartenenza al gruppo di utenti o dispositivi.

Passaggio 4: Configurazione del supplicant dell'endpoint

Questo è il passaggio più critico per la sicurezza. Per PEAP, utilizza l'MDM o le Group Policy per inviare un profilo WiFi preconfigurato ai dispositivi. Questo profilo DEVE specificare esplicitamente i nomi dei server RADIUS attendibili e la Root CA attendibile che ha emesso il certificato del server. Aspetto fondamentale, disabilita l'opzione che chiede agli utenti di considerare attendibili nuovi server o certificati.

Best Practice

1. Non affidarsi mai al giudizio dell'utente per i certificati: Quando si distribuisce PEAP o EAP-TTLS, preconfigura sempre i supplicant degli endpoint affinché considerino attendibili certificati server specifici. Affidarsi agli utenti che fanno clic su "Accetta" su un avviso di certificato compromette l'intero modello di sicurezza e espone la rete ad attacchi di rogue AP.
2. Automatizzare la gestione del ciclo di vita dei certificati: La scadenza dei certificati è una delle cause principali delle interruzioni di 802.1X. Implementa processi automatizzati di monitoraggio e rinnovo sia per i certificati del server RADIUS che per i certificati client nelle distribuzioni EAP-TLS.
3. Implementare WPA3-Enterprise: Laddove il supporto dei client lo consenta, passa a WPA3-Enterprise. Questo impone l'uso di Protected Management Frames (PMF) e offre un'opzione di suite di sicurezza a 192 bit, fornendo protezioni crittografiche più forti rispetto a WPA2.
4. Segmentare la rete: Utilizza gli attributi RADIUS (come Filter-Id o Tunnel-Private-Group-Id) to dynamically assign authenticated users to specific VLANs based on their role, isolando il traffico guest dalle risorse aziendali. Per saperne di più sulla progettazione di reti moderne, consulta I vantaggi principali di SD-WAN per le aziende moderne .

Risoluzione dei problemi e mitigazione dei rischi

Le modalità di errore comuni nelle distribuzioni EAP riguardano in genere la convalida dei certificati e l'integrazione con l'identity provider.

• Sintomo: I client non riescono a connettersi dopo un aggiornamento del server RADIUS.
  • Rischio: Il nuovo certificato del server non è stato emesso dalla Root CA considerata attendibile dai client, oppure il nome del server è cambiato.
  • Mitigazione: Testa sempre i rollover dei certificati in un ambiente di staging. Assicurati che la nuova catena di certificati sia completamente attendibile per tutti i profili di endpoint prima di applicarla alla produzione.
• Sintomo: I dispositivi iOS si connettono correttamente, ma i dispositivi Windows falliscono.
  • Rischio: I supplicant di Windows sono spesso più severi nella convalida della Server Name Indication (SNI) o degli attributi EKU (Extended Key Usage) specifici sul certificato del server.
  • Mitigazione: Verifica che il certificato del server includa l'EKU 'Server Authentication' e che la SAN corrisponda al nome configurato nel profilo WiFi di Windows.

ROI e impatto aziendale

Il passaggio a un metodo EAP robusto offre un valore aziendale significativo che va oltre la semplice sicurezza. Eliminando le password condivise, i team IT riducono il sovraccarico operativo dei ticket di helpdesk relativi alla reimpostazione delle password o a PSK compromesse. In ambienti come l' Hospitality , dove il turnover del personale può essere elevato, l'autenticazione basata su certificati (EAP-TLS) garantisce che l'accesso venga revocato automaticamente quando un dispositivo viene inizializzato o un certificato scade, senza dover modificare una password globale.

Inoltre, un'autenticazione forte è un prerequisito per i framework di conformità come PCI DSS e GDPR. Dimostrando controlli di accesso robusti, le organizzazioni mitigano il rischio di sanzioni normative e danni alla reputazione associati alle violazioni dei dati. Per uno sguardo più ampio sull'aggiornamento dell'infrastruttura delle strutture, consulta Soluzioni WiFi moderne per l'hospitality che i tuoi ospiti meritano .

Briefing del podcast

Ascolta il nostro briefing tecnico di 10 minuti sui metodi EAP, che copre le strategie di implementazione e gli errori comuni: