IKEv2 su Windows e FortiGate: tre impostazioni che le persone fondono

Un accordo IKEv2 tra un client Windows e un gateway FortiGate continua a fallire, e la ricerca di un numero che non corrisponde produce un elenco di numeri ancora più lungo. L’elenco diventa gestibile solo quando viene diviso in tre righe che falliscono in modo indipendente: lo scambio di chiavi che protegge IKE, la protezione applicata alla CHILD SA e l’autenticazione che dimostra chi è ciascuna parte. I numeri di gruppo compaiono in due di quelle righe e significano cose diverse.

Tre righe che falliscono in modo indipendente

La prima riga è lo scambio di chiavi all’interno di IKE stesso, che genera le chiavi che proteggono la negoziazione. La seconda è la proposta per la CHILD SA, che protegge il traffico trasportato dal tunnel. La terza è l’autenticazione, che decide cosa presenta ciascuna parte e come l’altra lo convalida.

I guasti si verificano in punti diversi. Un guasto dello scambio ferma la negoziazione prima che esista un tunnel. Un guasto della CHILD SA avviene dopo il successo dell’autenticazione, a volte solo al rinnovo delle chiavi. Un guasto dell’autenticazione può sembrare un guasto dello scambio nei log se si legge solo il primo errore.

Separare le righe non è contabilità. Cambia quale impostazione vale la pena modificare e impedisce la mossa più costosa di tutto questo ambito, cioè rigenerare certificati funzionanti per correggere una discrepanza di proposta. Il cambiamento di una riga non dovrebbe mai costringere le altre due a cambiare con essa. Quell’indipendenza è l’intero scopo di scriverle separatamente.

Cosa controllano i due campi di Windows

Windows tiene separati due campi: DHGroup configura lo scambio IKE stesso, mentre PfsGroup configura la politica IPsec che protegge il traffico nel tunnel. Appartengono a fasi diverse. Confrontare un campo IKE di Windows con un valore di fase 2 di FortiGate verifica la coppia sbagliata, e i numeri possono coincidere mentre lo scambio sottostante continua a fallire.

Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSA

Il secondo e il terzo comando riportano le associazioni di sicurezza che esistono davvero, ed è la cosa più vicina a una risposta che un client può darvi. Un’associazione in modalità principale senza un’associazione in modalità rapida è un problema della CHILD SA, ed è il segno di una discrepanza di fase 2 più che di un problema di certificato.

Annotate cosa è stato offerto e cosa è stato selezionato in un tentativo. Un elenco offerto che contiene una proposta accettabile e una proposta selezionata che non corrisponde alla politica del gateway è un disaccordo di configurazione, non un mistero di interoperabilità.

Un gruppo di curva ellittica non sceglie la vostra chiave di firma

L’inferenza errata più persistente in questo ambito è che scegliere un gruppo DH a curva ellittica richieda un certificato a curva ellittica. Un gruppo DH fornisce materiale per lo scambio di chiavi; l’algoritmo di firma è negoziato dal quadro di autenticazione, e sono due decisioni separate in IKEv2.

RFC 7427 esiste proprio perché quelle decisioni erano in precedenza intrecciate, e definisce come gli algoritmi di firma vengono annunciati e selezionati indipendentemente dallo scambio di chiavi. Un gateway può supportare contemporaneamente un gruppo di curva e una scelta di schemi di firma.

Quindi, quando una negoziazione fallisce dopo un cambio di gruppo, guardate il metodo di autenticazione prima di guardare il tipo di chiave del certificato. Cambiare un certificato è un’operazione lenta e rischiosa che raramente è la risposta, e farlo per primo distrugge la capacità di capire quale modifica abbia davvero aiutato. Leggete la riga dell’autenticazione prima di toccare l’archivio dei certificati.

Tenete entrambi in righe separate del foglio d’accordo e l’errore smetterà di essere tentante. Una riga elenca i gruppi, l’altra elenca schemi di firma e identità, e nessuna è prova dell’altra.

Mettete ogni chiave privata con il suo proprietario reale

Un gateway che presenta il proprio certificato ha bisogno della chiave privata che vi corrisponde. Un peer che convalida una catena ha bisogno del certificato della CA e, in particolare, non ha bisogno della chiave di firma della CA. Confondere questi tre artefatti è il modo in cui le persone finiscono per importare una chiave privata di CA in un dispositivo VPN per far comparire un certificato in un’altra categoria.

Su FortiOS i ruoli sono distinti: un certificato locale con la sua chiave, un certificato remoto usato per identificare un peer e una voce di CA remota che stabilisce fiducia nei certificati firmati da quella CA. Una voce di CA remota senza chiave privata non è incompleta; è corretta per il suo scopo.

Le chiavi di firma di CA importate ampliano l’autorità di chiunque possa leggere quel dispositivo. Non risolvono nemmeno la normale convalida del peer, perché la convalida richiede il certificato pubblico e la decisione di fiducia, non la capacità di emettere nuovi certificati.

Tenete la chiave di firma della CA presso il processo dell’emittente stesso e annotate quale dispositivo detiene quale chiave. Una tabella breve di proprietari vale più di una tabella più lunga di algoritmi quando un audit chiede chi potrebbe impersonare chi. Nessuno importa una chiave che sa essere solo d’inventario. Scrivete l’inventario prima dell’incidente, non dopo.