SA-levetider i IKEv2: mjuk nøkkelfornying, hardt utløp, separat reautentisering

Timar avgjer når nøklane til ein tunnel blir erstatta, og dei to tersklane som er involverte blir ofte lesne som éin. Det er dei ikkje. Ei mjuk levetid ber peer'en byggje ei erstatning medan den noverande tryggingsassosiasjonen framleis ber trafikk, og ei hard levetid er fristen deretter den gamle assosiasjonen er borte, uansett om erstatninga verka. Mellom dei ligg eit overlappsvindauge som finst for at pakkar ikkje skal falle i eit hol.

Kva ei levetid eigentleg avgrensar

Ein IPsec-tryggingsassosiasjon er ein bunt kryptografisk tilstand: nøklar for éi retning, ein tryggingsparameterindeks, eit algoritmesett og ein selektor. Levetida avgrensar kor lenge denne tilstanden kan brukast, noko som avgrensar kor mykje trafikk éin nøkkel vernar. Det er eit inneslutningstiltak for nøkkelen, ikkje ei utsegn om kor lenge ein brukarsesjon bør vare.

IKE-kontrollassosiasjonar har eigne nøklar og eigne levetider, åtskilde frå barnassosiasjonane som ber data. Det er den første staden folk blandar saman to tidsplanar.

Mjuk startar utskiftinga, hard avsluttar den gamle tilstanden

Når den mjuke terskelen nærmar seg, startar peer'en ei utskifting. Implementasjonar utløyser vanlegvis tidleg og randomiserer augneblinken slik at eit hovud med hundrevis av tunnelar ikkje fornyar alle nøklane på éin gong. I IKEv2 er utskiftinga ein CREATE_CHILD_SA-utveksling med ferske nonce, pluss ein Diffie-Hellman-utveksling når perfekt forward secrecy er konfigurert. Resultatet er eit nytt par assosiasjonar med nye nøklar.

Overlappet betyr noko. I ein kort periode kan peer'en halde både den gamle og den nye assosiasjonen, og eit opptak kan vise to sett identifikatorar. Det er mekanismen som verkar, ikkje ein feil.

Den harde terskelen gir inga nåde. Viss utskiftinga ikkje er fullført innan då, må den gamle assosiasjonen pensjonerast, og trafikk som berre blir verna av han stoppar. Gjentekne mislukka nøkkelfornyingar som går heilt til hardt utløp er det operasjonelle signalet å undersøkje, fordi tunnelen blir halden oppe av ein frist kvar syklus.

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

Tid er ikkje den einaste grensa. Implementasjonar kan avgrense byta eller pakkane som éin nøkkel vernar, og ein travel tunnel vil nå ei bruksgrense lenge før ein timer på fleire timar. strongSwan tilbyr separate innstillingar for levetid og margin for tid, byte og pakkar, noko som betyr at det effektive fornyingspunktet er den terskelen som kjem først, minus den konfigurerte margen.

Når ein tunnel blir fornya langt oftare enn dei konfigurerte timane antydar, sjekk byte- og pakkegrensene før du klandrar klokka. Ei metta lenkje og ei ledig lenkje med dei same tidsinnstillingane vil ha synleg ulike fornyingsratar, og berre éi av dei følgjer timeren.

Kvar peer handhevar sin eigen policy

IKEv2 forhandlar ikkje éi enkelt levetid som båe peer'ar må vise identisk. Kvar side nyttar sin lokale policy og kan starte utskifting når si eiga grense nærmar seg, som skildra i RFC 7296 avsnitt 2.8. Så eit avvik mellom to peer'ars konfigurerte timar er ikkje automatisk ein feil, sjølv om svært ulike verdiar kan skape uro viss den eine sida stadig erstattar tilstand som den andre nettopp installerte.

Koordinering betyr kompatibel åtferd: overlappsvindauge som er lange nok for utvekslinga, marginar som gir rom for nye forsøk, og overvaking som viser kva side som starta kvar fornying.

Nøkkelfornying er ikkje reautentisering

Ei nøkkelfornying oppdaterer nøklar under det eksisterande autentiserte forholdet. Ei reautentisering gjentek identitetskontrollen, anten det er ei sertifikatutveksling eller ein EAP-samtale. Dei to går etter separate tidsplanar, og ei vellukka fornying seier ingenting om kontoen framleis bør ha tilgang.

Den skilnaden er viktig for tilbakekalling. Deaktivering av ein konto, tilbakekalling av eit sertifikat eller avslutting av ein sesjon er tilgangsavgjerder som krev eksplisitt policy i implementasjonen; dei følgjer ikkje av SA-timeren, og ei nøkkelfornying kan halde fram lystig for ein identitet som allereie er fråteken rettar.

Kva som skal loggførast per tunnel

Logg kva assosiasjon som utløyste fornyinga, dei gamle og nye identifikatorane, kva terskel som slo til og om utskiftinga vart fullført innanfor overlappet. Dei fire felta gjer eit fornyingsproblem synleg før det blir eit avbrot, og dei skil ein aggressiv policy frå ein som sviktar.

Hald tidsplanen for fjerning av tilgang ved sida av den loggen i staden for inne i han. Kryptografisk hygiene og identitetspolicy er ulike kontrollar, og ein tunnel som roterer nøklar i tide kan framleis halde ein sesjon som ingen hadde til hensikt å behalde.