Durata delle SA in IKEv2: rinnovo chiavi morbido, scadenza rigida, riautenticazione separata

I timer decidono quando le chiavi di un tunnel vengono sostituite, e le due soglie coinvolte vengono spesso lette come una sola. Non lo sono. Una vita utile morbida chiede al peer di costruire una sostituzione mentre l'associazione di sicurezza attuale trasporta ancora traffico, e una vita utile rigida è la scadenza dopo la quale l'associazione vecchia sparisce, che la sostituzione abbia funzionato o no. Tra le due c'è una finestra di sovrapposizione che esiste perché i pacchetti non cadano in un vuoto.

Che cosa limita davvero una vita utile

Un'associazione di sicurezza IPsec è un fascio di stato crittografico: chiavi per una direzione, un indice dei parametri di sicurezza, un insieme di algoritmi e un selettore. La vita utile limita per quanto tempo quello stato può essere usato, il che limita quanto traffico protegge una chiave. È una misura di contenimento per la chiave, non un'affermazione su quanto debba durare una sessione utente.

Le associazioni di controllo IKE hanno chiavi proprie e vite utili proprie, separate dalle associazioni figlie che trasportano dati. È il primo punto in cui si confondono due calendari.

Il morbido avvia la sostituzione, il rigido chiude lo stato vecchio

Quando la soglia morbida si avvicina, il peer avvia una sostituzione. Le implementazioni di solito scattano presto e randomizzano il momento perché un headend con centinaia di tunnel non rinnovi tutte le chiavi insieme. In IKEv2 la sostituzione è uno scambio CREATE_CHILD_SA che porta nonce nuovi, più uno scambio Diffie-Hellman quando è configurata la segretezza in avanti perfetta. Il risultato è una nuova coppia di associazioni con chiavi nuove.

La sovrapposizione conta. Per un breve periodo il peer può tenere l'associazione vecchia e quella nuova, e una cattura può mostrare due insiemi di identificatori. È il meccanismo che funziona, non un guasto.

La soglia rigida non perdona. Se la sostituzione non è completata a quel punto, l'associazione vecchia deve essere ritirata e il traffico protetto solo da essa si ferma. Rinnovi di chiavi falliti ripetuti che arrivano fino alla scadenza rigida sono il segnale operativo da indagare, perché il tunnel viene sostenuto da una scadenza a ogni ciclo.

I limiti d'uso possono scattare prima di qualsiasi orologio

Il tempo non è l'unico limite. Le implementazioni possono limitare i byte o i pacchetti protetti da una chiave, e un tunnel trafficato raggiungerà un limite d'uso molto prima di un timer di molte ore. strongSwan espone impostazioni separate di vita utile e margine per tempo, byte e pacchetti, il che significa che il punto effettivo di rinnovo è la soglia che arriva prima, meno il margine configurato.

Quando un tunnel si rinnova molto più spesso di quanto suggeriscano le ore configurate, controllate i limiti di byte e pacchetti prima di incolpare l'orologio. Un collegamento saturo e uno inattivo con le stesse impostazioni di tempo avranno tassi di rinnovo delle chiavi visibilmente diversi, e solo uno dei due segue il timer.

Ogni peer applica la propria politica

IKEv2 non negozia un'unica vita utile che entrambi i peer debbano mostrare in modo identico. Ciascun lato applica la propria politica locale e può avviare la sostituzione quando il proprio limite si avvicina, come descritto in RFC 7296 sezione 2.8. Quindi una discrepanza tra le ore configurate di due peer non è automaticamente un difetto, anche se valori molto diversi possono produrre agitazione se un lato continua a sostituire stato che l'altro ha appena installato.

Coordinare significa comportamento compatibile: finestre di sovrapposizione abbastanza lunghe per lo scambio, margini che lasciano spazio ai tentativi ripetuti e monitoraggio che mostra quale lato ha avviato ogni rinnovo.

Rinnovare le chiavi non è riautenticare

Un rinnovo delle chiavi aggiorna le chiavi nell'ambito della relazione autenticata esistente. Una riautenticazione ripete il controllo dell'identità, che si tratti di uno scambio di certificati o di una conversazione EAP. Le due funzioni seguono calendari separati e un rinnovo riuscito non dice nulla sul fatto che l'account debba ancora avere accesso.

Questa distinzione conta per la revoca. Disattivare un account, revocare un certificato o terminare una sessione sono decisioni di accesso che richiedono una politica esplicita nell'implementazione; non derivano dal timer della SA, e un rinnovo delle chiavi può continuare tranquillamente per un'identità già privata dei permessi.

Che cosa registrare per tunnel

Registrate quale associazione ha innescato il rinnovo, gli identificatori vecchio e nuovo, quale soglia è scattata e se la sostituzione si è completata dentro la sovrapposizione. Questi quattro campi rendono visibile un problema di rinnovo prima che diventi un'interruzione, e distinguono una politica aggressiva da una che sta fallendo.

Tenete il calendario di rimozione dell'accesso accanto a quel record, non al suo interno. L'igiene crittografica e la politica di identità sono controlli diversi, e un tunnel che ruota le chiavi puntualmente può ancora tenere una sessione che nessuno intendeva conservare.