Come l’autenticazione ibrida IKEv1 si trasferisce nell’autenticazione utente IKEv2

Ogni profilo VPN legacy che chiede un certificato server e poi un nome utente porta due eventi di autenticazione dentro un solo scambio, e quella forma sopravvive al protocollo che l’ha introdotta. La modalità ibrida IKEv1 è stata costruita esattamente per questo: il gateway si dimostra con una chiave pubblica mentre l’utente si dimostra più tardi tramite XAuth. IKEv2 esprime la stessa idea in due passi con meccanismi diversi, e proprio in quelle differenze falliscono le migrazioni. Nessun numero di versione converte l’uno nell’altro, e copiare i vecchi nomi delle opzioni in un profilo nuovo produce un client che negozia e poi non autentica nulla.

Che cosa faceva la modalità ibrida dentro IKEv1

In un profilo ibrido il responder firma lo scambio della fase uno con il proprio certificato mentre l’initiator non ne presenta alcuno di proposito. La prova di identità è quindi asimmetrica, ed è ciò che ha permesso a un gateway di mantenere la propria PKI esistente mentre gli utenti mantenevano le password della directory. Terminata la fase uno, XAuth viene eseguito come richiesta e risposta che trasporta gli attributi di nome utente e password dentro il canale ISAKMP ormai cifrato.

Notate dove finisce la fiducia. Il certificato risponde a quale gateway è arrivato il client; XAuth risponde a quale utente vuole l’accesso. Nessuno dei due sostituisce l’altro, e un client configurato per accettare qualsiasi certificato server ha scartato in silenzio la prima risposta. L’etichetta ibrida viene usata anche per la modalità aggressiva con chiave precondivisa più XAuth, una disposizione diversa con la stessa esperienza utente, quindi leggete il profilo e non il nome. Entrambe le varianti derivano da draft che non sono mai diventati standard, ed è per questo che due fornitori possono implementare la modalità ibrida e non interoperare con nessuno dei due.

Come IKEv2 arriva alle stesse due prove

IKEv2 divide il lavoro tra IKE_SA_INIT e IKE_AUTH. Il primo scambio concorda proposte e chiavi senza alcuna identità; il secondo trasporta IDi, IDr e i payload AUTH. Con EAP il primo payload AUTH dell’initiator esce vuoto, il responder si autentica per primo con il proprio certificato e la propria firma, e la conversazione EAP scorre poi dentro i messaggi IKE_AUTH.

Il meccanismo che rende tutto questo sicuro è il materiale di chiave. Un metodo EAP riuscito esporta una chiave di sessione, e il payload AUTH finale dell’initiator viene calcolato da essa, così la prova dell’utente e le chiavi del tunnel restano legate. XAuth non ha nulla di equivalente: i suoi attributi arrivano dopo la fase uno e non contribuiscono in alcun modo alle chiavi. È esattamente quel vuoto che l’architettura IKEv2 è stata progettata per colmare, ed è per questo che un accesso IKEv2 funzionante convalida il certificato server prima di chiedere qualsiasi cosa.

Questo ordine è anche una diagnostica utile. Quando un client si lamenta delle credenziali prima di avervi mostrato un certificato, non sta affatto facendo uno scambio EAP IKEv2.

Tenete separate tre identità

Una migrazione va storta quando tre identità collassano in un solo campo. C’è l’identità del gateway che il client convalida, di solito un nome DNS nel subject o nel SAN del certificato. C’è l’identità utente presentata in EAP, che può essere un accesso di dominio, un indirizzo o una stringa di identità EAP esplicita. E c’è la fonte di autorizzazione che mappa quell’utente su reti e rotte.

La sintassi swanctl di strongSwan rende visibile la separazione: la connessione imposta remote { auth = pubkey } per il gateway e local { auth = eap-mschapv2 } per l’utente, con l’identità EAP trasportata a parte.

Quando l’identità utente nel nuovo profilo differisce dai vecchi attributi XAuth, per esempio un UPN invece di un nome breve, il server di autenticazione vede un utente sconosciuto e il guasto sembra una password sbagliata. Controllate la stringa di identità prima di controllare la credenziale.

Mappate le opzioni, poi aspettatevi le trappole

La mappatura è breve e ogni riga ha una trappola che compare solo al momento dell’autenticazione.

Nessuna di quelle righe è una semplice rinomina. Il payload di configurazione consegna indirizzi e resolver tramite una lista di attributi tipizzati, mentre lo spazio degli attributi di XAuth era un’invenzione a sé; trattarli come intercambiabili è il modo in cui un profilo finisce per chiedere un’impostazione che il gateway non invierà mai.

I selettori di traffico meritano un avvertimento a parte. IKEv1 esprimeva il traffico interessante tramite proxy ID legati a uno scambio in modalità rapida, mentre IKEv2 negozia i selettori durante IKE_AUTH e il responder può restringerli. Un disallineamento produce una IKE SA stabilita senza SA figlia, che alcuni client mostrano tranquillamente come connessa.

Trattate la vecchia connessione come un confine

La RFC 9395 depreca IKEv1, quindi una connessione ibrida legacy è un confine di compatibilità con una data sopra, non una fondazione. Tenete entrambi i profili in funzione fianco a fianco durante il cambiamento, perché il test che conta non è se il nuovo profilo si alza, ma se lo stesso utente sullo stesso dispositivo raggiunge le stesse risorse.

Mantenete rigorosa la convalida dei certificati per tutto il tempo. Appena il client smette di presentare il proprio certificato, la tentazione è allentare il controllo del server finché l’handshake non si completa, e questo baratta l’unica prova rimasta con un’icona verde.

Scrivete quattro cose prima di ritirare il vecchio profilo: il metodo EAP, la stringa di identità, la fonte di autorizzazione e la data in cui finisce il supporto.