SA-levetider i IKEv2: myk nøkkelfornyelse, hardt utløp, separat reautentisering

Timere avgjør når nøklene til en tunnel erstattes, og de to tersklene som er involvert leses ofte som én. Det er de ikke. En myk levetid ber peer'en bygge en erstatning mens den nåværende sikkerhetsassosiasjonen fortsatt bærer trafikk, og en hard levetid er fristen deretter den gamle assosiasjonen er borte, uansett om erstatningen virket. Mellom dem ligger et overlappsvindu som finnes for at pakker ikke skal falle i et hull.

Hva en levetid egentlig avgrenser

En IPsec-sikkerhetsassosiasjon er en bunt kryptografisk tilstand: nøkler for én retning, en sikkerhetsparameterindeks, et algoritmesett og en selektor. Levetiden avgrenser hvor lenge denne tilstanden kan brukes, noe som begrenser hvor mye trafikk én nøkkel beskytter. Det er en inneslutningsforanstaltning for nøkkelen, ikke en uttalelse om hvor lenge en brukersesjon bør vare.

IKE-kontrollassosiasjoner har egne nøkler og egne levetider, atskilt fra barnassosiasjonene som bærer data. Det er det første stedet folk blander sammen to tidsplaner.

Myk starter utskiftingen, hard avslutter den gamle tilstanden

Når den myke terskelen nærmer seg, starter peer'en en utskifting. Implementasjoner utløser vanligvis tidlig og randomiserer øyeblikket slik at et hode med hundrevis av tunneler ikke fornyer alle nøklene på én gang. I IKEv2 er utskiftingen en CREATE_CHILD_SA-utveksling med ferske noncer, pluss en Diffie-Hellman-utveksling når perfekt forward secrecy er konfigurert. Resultatet er et nytt par assosiasjoner med nye nøkler.

Overlappet betyr noe. I en kort periode kan peer'en holde både den gamle og den nye assosiasjonen, og en opptak kan vise to sett identifikatorer. Det er mekanismen som virker, ikke en feil.

Den harde terskelen gir ingen nåde. Hvis utskiftingen ikke er fullført innen da, må den gamle assosiasjonen pensjoneres, og trafikk som bare beskyttes av den stopper. Gjentatte mislykkede nøkkelfornyelser som går helt til hardt utløp er det operasjonelle signalet å undersøke, fordi tunnelen holdes oppe av en frist hver syklus.

Bruksgrenser kan slå til før noen som helst klokke

Tid er ikke den eneste grensen. Implementasjoner kan begrense bytene eller pakkene som én nøkkel beskytter, og en travel tunnel vil nå en bruksgrense lenge før en timer på flere timer. strongSwan tilbyr separate innstillinger for levetid og margin for tid, byte og pakker, noe som betyr at det effektive fornyelsespunktet er den terskelen som kommer først, minus den konfigurerte marginen.

Når en tunnel fornyes langt oftere enn de konfigurerte timene antyder, sjekk byte- og pakkegrensene før du klandrer klokken. En mettet lenke og en ledig lenke med de samme tidsinnstillingene vil ha synlig forskjellige fornyelsesrater, og bare én av dem følger timeren.

Hver peer håndhever sin egen policy

IKEv2 forhandler ikke én enkelt levetid som begge peer'er må vise identisk. Hver side anvender sin lokale policy og kan starte utskifting når dens egen grense nærmer seg, som beskrevet i RFC 7296 avsnitt 2.8. Så et avvik mellom to peer'ers konfigurerte timer er ikke automatisk en feil, selv om svært ulike verdier kan skape uro hvis den ene siden stadig erstatter tilstand som den andre nettopp installerte.

Koordinering betyr kompatibel atferd: overlappsvinduer som er lange nok for utvekslingen, marginer som gir rom for nye forsøk, og overvåking som viser hvilken side som startet hver fornyelse.

Nøkkelfornyelse er ikke reautentisering

En nøkkelfornyelse oppdaterer nøkler under det eksisterende autentiserte forholdet. En reautentisering gjentar identitetskontrollen, enten det er en sertifikatutveksling eller en EAP-samtale. De to går etter separate tidsplaner, og en vellykket fornyelse sier ingenting om hvorvidt kontoen fortsatt bør ha tilgang.

Den forskjellen er viktig for tilbakekalling. Deaktivering av en konto, tilbakekalling av et sertifikat eller avslutning av en sesjon er tilgangsbeslutninger som krever eksplisitt policy i implementasjonen; de følger ikke av SA-timeren, og en nøkkelfornyelse kan fortsette lystig for en identitet som allerede er fratatt rettigheter.

Hva som skal registreres per tunnel

Logg hvilken assosiasjon som utløste fornyelsen, de gamle og nye identifikatorene, hvilken terskel som slo til og om utskiftingen ble fullført innenfor overlappet. De fire feltene gjør et fornyelsesproblem synlig før det blir et avbrudd, og de skiller en aggressiv policy fra en som svikter.

Hold tidsplanen for fjerning av tilgang ved siden av den registreringen i stedet for inne i den. Kryptografisk hygiene og identitetspolicy er forskjellige kontroller, og en tunnel som roterer nøkler i tide kan fortsatt holde en sesjon som ingen hadde til hensikt å beholde.