EAP o certificati client? Decidere l’autenticazione IKEv2

Il vostro gateway può dimostrare la propria identità con un certificato mentre dimostra la vostra tramite EAP, e questa combinazione è comune, non contraddittoria. I due meccanismi rispondono a domande diverse: questo endpoint è quello che mi aspetto, e questo utente o dispositivo è autorizzato. Vedere EAP in un profilo non disattiva la validazione del server. È leggere il profilo come un’unica impostazione che spinge le persone a reimpostare la credenziale sbagliata.

Stabilite quale asserzione è fallita prima di toccare uno dei due oggetti. La fase del guasto ve lo dice, se la leggete in ordine.

Due credenziali, due asserzioni

Un certificato server lega un nome a una chiave, e il client verifica quel legame rispetto al proprio archivio di fiducia. Un certificato client lega un’identità a una chiave, e il gateway verifica che il certificato presentato si concateni a qualcosa di cui si fida. EAP trasporta uno scambio di autenticazione il cui contenuto dipende dal metodo scelto. Sono tre strutture con durate, proprietari e modalità di guasto diversi.

Una passphrase che sblocca una chiave privata non è una password di account, anche quando i due prompt compaiono a pochi secondi di distanza. Una è locale all’archivio delle chiavi del dispositivo, e l’altra è validata da un server di autenticazione dietro il gateway.

EAP è un contenitore, non un metodo

EAP è un framework: il gateway e il client negoziano un metodo, e il metodo decide se sono coinvolti una password, un token, uno scambio interno incapsulato o un certificato, come espone la documentazione di strongSwan su IKEv2. Per questo EAP-TLS non assomiglia affatto a EAP-MSCHAPv2 dal lato client, anche se entrambi compaiono come EAP in un menu. Un profilo che nomina solo EAP non vi ha detto cosa verrà chiesto all’utente.

Leggete il metodo e il backend insieme. Il backend determina il formato dell’account, il comportamento di blocco e ciò che un reset della password cambia davvero, e nulla di tutto ciò è visibile nel profilo del client.

La distribuzione mista è normale

Certificato server più EAP per l’utente è la forma che distribuiscono la maggior parte dei gateway di accesso remoto, perché dà al client un endpoint verificabile e all’operatore un’identità per utente in un archivio account centrale. Esistono anche distribuzioni con certificati client, di solito dove l’identità del dispositivo conta più di una password. Entrambe sono legittime, e l’errore è supporre che quello che avete visto la settimana scorsa sia quello che avete davanti.

Chiedete all’operatore il metodo e il formato dell’account documentati invece di dedurli dai nomi dei campi di un client.

Decidere dalla fase del guasto

Ordinate le osservazioni. Un errore di fiducia prima di qualsiasi prompt utente è un problema di certificato server e nessuna password lo risolverà. Un prompt seguito da un rifiuto è un problema di autenticazione utente, con il metodo EAP e il backend come sospetti. Un’autenticazione riuscita seguita da un guasto child-SA non è né l’uno né l’altro.

Contano altre due distinzioni. Un client che rifiuta il certificato server di solito segnala una discrepanza di nome o un’autorità sconosciuta, che è una questione di archivio di fiducia. Un gateway che rifiuta l’utente spesso registra il metodo EAP e una categoria di motivo, che è una questione di account o di policy.

Gestire i due modelli

Con i certificati il lavoro è emissione, rinnovo, revoca e rimozione dei dispositivi smarriti, e avviene secondo un calendario che controllate voi. Con EAP il lavoro è il ciclo di vita dell’account, il supporto dei metodi su ogni piattaforma client e qualunque secondo fattore richieda il backend. Nessun modello è più economico in astratto; caricano team diversi. Annotate quale usa davvero la vostra distribuzione, perché gli script di supporto differiscono più della configurazione.

Teneteli separati nelle vostre note. Una scadenza di certificato produce un guasto a una data, un blocco dell’account produce un guasto dopo un cambio di password, e una discrepanza di metodo produce un guasto su una sola piattaforma.

Dopo che l’identità è accettata

L’autenticazione è una porta. L’associazione di sicurezza figlia, i selettori di traffico, il DNS e i permessi propri dell’applicazione sono porte successive, e ciascuna fallisce alle proprie condizioni. Un’identità accettata che non raggiunge nulla non è un problema di autenticazione.

Registrate il metodo, l’account o il certificato usato e la fase che è fallita. Quella nota trasforma l’incidente successivo in una ricerca invece che in un esperimento.