Due identità in un unico accesso IKEv2: prima la macchina, poi l'utente

Un certificato client viene convalidato, il primo scambio si completa, e poi la connessione si ferma con un errore su un giro di autenticazione aggiuntivo. Nulla nella catena dei certificati è sbagliato e nulla nella rete è cambiato. Il gateway è configurato per esigere una seconda prova dal lato che si connette, e il client non ne invia mai una. Decidere chi prova cosa, e in quale ordine, è l'intero compito, e comincia leggendo la politica dall'endpoint su cui siete. Due prove di tipo diverso, in un ordine fisso, sono una decisione di progetto e non una casella di controllo.

Il sintomo: fallimento dopo una prima prova riuscita

Il primo scambio si completa e il registro sembra sano, finché il gateway chiede un'identità utente tramite EAP. Allora la stretta di mano si blocca o restituisce un errore di protocollo che nomina il giro aggiuntivo. Un certificato macchina perfettamente valido viene rifiutato per un motivo che non ha nulla a che vedere con la sua validità. La politica chiedeva una seconda prova, e la risposta del client non è mai arrivata.

Entrambe le descrizioni di quel fallimento sono esatte a seconda di dove vi trovate. Dal lato del client sembra un server che rifiuta un certificato valido, e dal lato del server sembra un client che non riesce a completare l'accesso. Lo stesso evento si legge come un problema di fiducia in un registro e un problema di capacità nell'altro. Solo la politica configurata vi dice quale sia.

Che cosa aggiunge l'estensione e che cosa no

IKEv2 porta un'estensione per eseguire più di uno scambio di autenticazione dentro una singola sessione. RFC 4739 tratteggia, fra le altre sequenze, un client che prova un'identità di certificato e poi autentica una persona tramite EAP. Il documento è Experimental, il che significa che nessuna implementazione vi deve la funzione. Non date nulla per scontato sul supporto finché il pari non lo negozia.

Entrambi i lati devono supportare l'estensione e concordarla durante lo scambio. Un gateway configurato per un secondo giro non può obbligare un client a eseguirne uno, e un client che la supporta non la userà se il server non lo chiede. È questa asimmetria che fa sì che il fallimento si presenti di solito come timeout o errore di protocollo invece che come una dichiarazione chiara sulla capacità. Leggere la configurazione di un lato vi dice metà di ciò che accadrà.

Una prova per endpoint è la forma normale, e questo non è quel progetto. Il gateway presenta il suo certificato, l'utente risponde tramite EAP, e ciascun lato ha autenticato l'altro esattamente una volta. Quelle due prove vengono da endpoint opposti, quindi nessuna delle due dice qualcosa di separato sulla macchina e sulla persona che la usa.

EAP-TLS è una terza forma, e anche questa non è quella. Lì un certificato client viene presentato dentro un metodo EAP, quindi il client completa comunque una sola autenticazione IKE. Le credenziali possono sembrare identiche al caso a più giri mentre il protocollo porta un giro invece di due. Per questo un progetto copiato da un'installazione EAP-TLS fallisce proprio nel punto in cui si attende la seconda prova.

Lo stesso file si legge diversamente sul gateway

Lo stesso file swanctl si legge diversamente a seconda di dove viene eseguito, ed è la parte su cui le persone inciampano. Sul portatile il gateway è il pari, e sul gateway lo è il portatile, quindi scrivete il lato local come chi sono io e il lato remote come chi accetterò. Un blocco local descrive come questo endpoint autentica se stesso, e un blocco remote dichiara che cosa esige dall'altro capo. Copiare un blocco fra i due file ne inverte il significato senza cambiare un solo carattere. Confrontare i due file non vi dice quasi nulla, perché le stesse parole significano cose opposte in ciascuno.

La posizione di una sezione ne fissa l'ordine salvo che un numero di giro la scavalchi. Perciò le sezioni local o remote aggiuntive descrivono giri aggiuntivi e non alternative, e il numero di giro esplicito nella la guida di riferimento di swanctl.conf esiste proprio per rendere deliberato quell'ordine. Senza di esso, spostare un blocco cambia il comportamento. Per questo anche due configurazioni che sulla carta sembrano equivalenti possono comportarsi in ordini opposti.

Quella regola d'ordine produce il modo di fallire che vale la pena ricordare. Un secondo blocco remote non è un'altra opzione accettabile; è una seconda richiesta, ed è per questo che una politica che si legge come o/o si comporta come e-poi. Una politica del gateway può accettare il certificato della macchina iscritta e poi esigere lo scambio EAP di quell'utente, in quell'ordine.

Distinguete i giri dai fattori indipendenti

Due giri non sono automaticamente due fattori indipendenti. Ripetere una prova, o tenere due credenziali nello stesso archivio, non dà la forza che il progetto doveva aggiungere. L'indipendenza è una proprietà di come sono custoditi i segreti e di ciò che li compromette, non di quanti scambi esegue il protocollo. Un progetto che conta i giri come fattori sopravvaluta ciò che ha. Quella distinzione conta soprattutto quando una domanda di conformità chiede quanti fattori usi davvero l'accesso.

Un certificato macchina prova il possesso della sua chiave accettata, e nulla più. Non è un'attestazione hardware e non è un rapporto di salute del dispositivo, quindi una politica che necessita di informazioni di postura necessita di un altro meccanismo. Nemmeno il campo subject è un'etichetta di inventario affidabile, perché il subject è scelto da chi ha emesso o iscritto il certificato. Se il progetto necessita della prova che la macchina sia sana, quella prova deve venire da un componente che misura la macchina.

Annotate che cosa prova davvero ogni giro prima di aggiungerlo. Quando due giri provano due volte la stessa cosa, il secondo aggiunge latenza e ticket di supporto invece di certezza. Quella nota è anche ciò che ferma una discussione sul fatto che il giro aggiuntivo valga il suo costo.

Scrivete la regola di abbinamento e provate i rifiuti

Decidete quali identità macchina possono abbinarsi a quali persone, e scrivete la regola dove vive l'applicazione. Due credenziali valide fianco a fianco non provano nulla sull'abbinamento, perché l'abbinamento è una decisione di autorizzazione e non un risultato di autenticazione. I registri di iscrizione o il backend di autenticazione devono applicare la relazione che l'organizzazione vuole.

Poi provate ciò che dovrebbe fallire: un utente accettato su una macchina non approvata, un utente non approvato che detiene la credenziale della macchina e un pari che non può eseguire il giro aggiuntivo. Se tutti e tre ricevono in silenzio lo stesso accesso, la politica descrive un'intenzione invece di applicarla. Confrontate la configurazione dichiarata con ciò che riporta il demone, perché una connessione che non ha mai corrisposto appare identica a una regola che è passata:

swanctl --list-conns
swanctl --list-sas

Verificate i giri negoziati e l'autorizzazione che ne deriva, non solo l'accesso riuscito. E non ricorrete a vecchie impostazioni IKEv1 XAuth come scorciatoia: fate corrispondere il protocollo, i ruoli, l'ordine e il comportamento reale del client invece di cancellare un giro necessario finché una connessione riesce. Cancellare il giro che fallisce è il modo in cui un progetto a due prove diventa in silenzio un progetto a una prova che nessuno ha esaminato. Tenete la cancellazione nel registro delle modifiche.