SA-livstider i IKEv2: mjuk nyckeluppdatering, hårt utgång, separat reautentisering

Timers avgör när en tunnels nycklar byts ut, och de två inblandade trösklarna läses ofta som en. Det är de inte. En mjuk livstid ber peeren bygga en ersättning medan den aktuella säkerhetsassociationen fortfarande bär trafik, och en hård livstid är den frist efter vilken den gamla associationen är borta, oavsett om ersättningen fungerade. Mellan dem ligger ett överlappningsfönster som finns för att paket inte ska falla i en lucka.

Vad en livstid egentligen begränsar

En IPsec-säkerhetsassociation är ett knippe kryptografiskt tillstånd: nycklar för en riktning, ett säkerhetsparameterindex, en algoritmuppsättning och en selektor. Livstiden begränsar hur länge tillståndet får användas, vilket begränsar hur mycket trafik en nyckel skyddar. Det är en inneslutningsåtgärd för nyckeln, inte ett påstående om hur länge en användarsession bör vara.

IKE-kontrollassociationer har egna nycklar och egna livstider, skilda från barnassociationerna som bär data. Det är den första platsen där människor blandar ihop två scheman.

Mjuk startar utbytet, hård avslutar det gamla tillståndet

När den mjuka tröskeln närmar sig startar peeren ett utbyte. Implementationer utlöser oftast tidigt och randomiserar ögonblicket så att ett huvud med hundratals tunnlar inte förnyar alla nycklar på en gång. I IKEv2 är utbytet ett CREATE_CHILD_SA-utbyte med färska nonce, plus ett Diffie-Hellman-utbyte när perfekt framåtriktad hemlighet är konfigurerad. Resultatet är ett nytt par associationer med nya nycklar.

Överlappningen spelar roll. Under en kort tid kan peeren hålla både den gamla och den nya associationen, och en fångst kan visa två uppsättningar identifierare. Det är mekanismen som fungerar, inte ett fel.

Den hårda tröskeln förlåter inte. Om utbytet inte är klart då måste den gamla associationen pensioneras, och trafik som bara skyddas av den stannar. Upprepade misslyckade nyckeluppdateringar som går ända till hårt utgång är den operativa signalen att undersöka, eftersom tunneln hålls uppe av en frist varje cykel.

Användningsgränser kan slå till före någon klocka

Tid är inte den enda gränsen. Implementationer kan begränsa byte eller paket som en nyckel skyddar, och en upptagen tunnel når en användningsgräns långt före en timer på flera timmar. strongSwan erbjuder separata inställningar för livstid och marginal för tid, byte och paket, vilket innebär att den effektiva förnyelsepunkten är den tröskel som kommer först, minus den konfigurerade marginalen.

När en tunnel förnyas mycket oftare än de konfigurerade timmarna antyder, kontrollera byte- och paketgränserna innan du skyller på klockan. En mättad länk och en inaktiv länk med samma tidsinställningar har synligt olika förnyelsetakt, och bara en av dem följer timern.

Varje peer upprätthåller sin egen policy

IKEv2 förhandlar inte en enda livstid som båda peerarna måste visa identiskt. Varje sida tillämpar sin lokala policy och kan initiera utbytet när den egna gränsen närmar sig, som beskrivs i RFC 7296 avsnitt 2.8. Så en avvikelse mellan två peerars konfigurerade timmar är inte automatiskt ett fel, även om mycket olika värden kan skapa oro om ena sidan ständigt ersätter tillstånd som den andra just installerade.

Samordning innebär kompatibelt beteende: överlappningsfönster som är tillräckligt långa för utbytet, marginaler som lämnar utrymme för nya försök, och övervakning som visar vilken sida som initierade varje förnyelse.

Nyckeluppdatering är inte reautentisering

En nyckeluppdatering fräschrar upp nycklar under den befintliga autentiserade relationen. En reautentisering upprepar identitetskontrollen, vare sig det är ett certifikatutbyte eller ett EAP-samtal. De två går enligt separata scheman och en lyckad uppdatering säger ingenting om huruvida kontot fortfarande bör ha åtkomst.

Den skillnaden spelar roll för återkallning. Att inaktivera ett konto, återkalla ett certifikat eller avsluta en session är åtkomstbeslut som kräver uttrycklig policy i implementationen; de följer inte av SA-timern, och en nyckeluppdatering kan fortsätta glatt för en identitet som redan berövats sina rättigheter.

Vad som ska loggas per tunnel

Logga vilken association som utlöste förnyelsen, de gamla och nya identifierarna, vilken tröskel som slog till och om utbytet slutfördes inom överlappningen. De fyra fälten gör ett förnyelseproblem synligt innan det blir ett avbrott, och de skiljer en aggressiv policy från en som misslyckas.

Håll schemat för borttagning av åtkomst bredvid den posten i stället för inuti den. Kryptografisk hygien och identitetspolicy är olika kontroller, och en tunnel som roterar nycklar i tid kan fortfarande hålla en session som ingen hade för avsikt att behålla.