Metodi EAP e certificati: EAP-TLS e PEAP-MSCHAPv2

Nella preparazione al SISE, la scelta del metodo EAP determina il livello di sicurezza dell’autenticazione 802.1X e la complessità operativa del deployment. Cisco ISE agisce da server RADIUS/EAP: negozia il metodo con il supplicant (tipicamente Cisco Secure Client / AnyConnect NAM, oppure il supplicant nativo dell’OS) attraverso l’authenticator (switch o WLC), che si limita a incapsulare EAP dentro RADIUS (EAP-over-LAN lato client, EAP-over-RADIUS lato ISE).

EAP-TLS: autenticazione mutua a certificati

EAP-TLS è il metodo più robusto perché usa un handshake TLS completo con autenticazione mutua: sia ISE sia l’endpoint presentano un certificato X.509 e verificano quello della controparte. Non esistono password in transito: l’identità dell’utente/macchina è legata alla chiave privata contenuta nel certificate store del client.

Requisiti chiave:

• Ogni endpoint deve possedere un certificato client valido, tipicamente emesso da una PKI interna (spesso via SCEP verso la CA, integrabile con il flusso BYOD/onboarding di ISE).
• ISE valida la catena del certificato client contro le CA presenti nel proprio Trusted Certificates Store, con il flag Trust for client authentication abilitato.
• Il Certificate Authentication Profile (CAP) definisce da quale campo estrarre l’identità (es. SAN o CN) e se fare binary comparison o lookup dell’identità in un identity store (AD, LDAP).

EAP-TLS è immune al furto di credenziali e al phishing, ma richiede una PKI matura e gestione del ciclo di vita dei certificati (revoca via CRL/OCSP, scadenza, rinnovo).

PEAP-MSCHAPv2: tunnel TLS + credenziali

PEAP costruisce un tunnel TLS server-side: solo ISE presenta un certificato (il suo system/EAP certificate). Dentro il tunnel cifrato viaggia il metodo interno, tipicamente EAP-MSCHAPv2, con cui l’utente si autentica tramite username/password validati contro Active Directory (o identity store interno).

Vantaggio: nessun certificato client da distribuire, deployment più rapido. Svantaggio: la sicurezza dipende interamente dalla robustezza della password e dalla validazione del certificato server da parte del supplicant. Se il client non valida il certificato di ISE, il tunnel può essere terminato da un attaccante.

EAP-FAST è concettualmente simile a PEAP ma usa una PAC invece di certificati per stabilire il tunnel, ed è la base per l’EAP chaining: autentica in un’unica sessione sia la macchina sia l’utente, permettendo policy tipo “accesso pieno solo se machine AND user autenticati”, utile contro l’uso di credenziali valide su dispositivi non gestiti.

Certificato di sistema ISE e catena di fiducia

Il certificato che ISE presenta al supplicant è il System Certificate con ruolo EAP Authentication (assegnato per-nodo, PSN). Perché l’handshake abbia successo:

1. Il certificato EAP di ISE deve essere firmato da una CA di cui l’endpoint ha la root/intermediate nel proprio trust store.
2. La catena completa (leaf + intermediate) deve essere installata e la CA importata anche nel Trusted Certificates Store di ISE.
3. Il supplicant deve avere il profilo configurato per validare il certificato server ed eventualmente fissare il nome del server (o la CA emittente) atteso.

Usare un certificato firmato da una CA pubblica semplifica il trust perché le root sono già presenti negli OS; una CA privata richiede la distribuzione della root agli endpoint (via GPO/MDM/onboarding).

Trappole tipiche d’esame

• L’endpoint non fida della CA che ha firmato il certificato EAP di ISE → l’autenticazione fallisce nell’handshake TLS: la soluzione è distribuire la root/intermediate CA al trust store dell’endpoint, non modificare il metodo EAP.
• Supplicant PEAP con “validate server certificate” disattivato → vulnerabilità man-in-the-middle (rogue RADIUS che ruba l’hash MSCHAPv2): la risposta giusta è abilitare la validazione del certificato server e specificare CA/nome server attesi.
• Scenario “nessuna password deve transitare / requisito autenticazione mutua” → la risposta è EAP-TLS, non PEAP-MSCHAPv2.
• Serve autenticare macchina e utente in un’unica sessione con policy combinata → EAP chaining con EAP-FAST, non PEAP semplice.
• EAP-TLS fallisce solo per alcuni endpoint mentre il trust è corretto → verificare scadenza/revoca (CRL/OCSP) del certificato client e il Certificate Authentication Profile (campo SAN/CN mappato correttamente all’identità in AD).
• Certificato EAP di ISE valido ma manca l’intermediate nella catena → il client non completa la validazione: importare la catena completa su ISE, non rigenerare il certificato.