Sleutel verversen, opnieuw verbinden of opnieuw authenticeren: wat heb je nodig?

Een sessie die al uren draait, houdt niet voor altijd dezelfde sleutels, en dat is de bedoeling. Drie verschillende gebeurtenissen worden sleutelrotatie genoemd: nieuw sessiemateriaal onder een bestaande associatie, een volledige herbouw van de verbinding en een herhaling van de identiteitscontrole. Elk heeft een andere trigger, andere kosten en een ander faalpatroon. Kies de verkeerde en de oplossing doet niets of haalt de tunnel zonder reden neer.

De beslissing hangt ervan af welke laag werkelijk is verlopen.

Drie bewerkingen die rotatie worden genoemd

Een sleutelverversing maakt nieuwe verkeerssleutels binnen de bestaande controlerelatie, met het mechanisme dat het protocol voorschrijft. IKEv2 doet dat met een nieuwe child-beveiligingsassociatie, TLS 1.3 met een sleutelupdatebericht en WireGuard met een nieuwe handshake zodra de tijd- of berichtlimieten zijn bereikt. De tunneladressen en de geauthenticeerde identiteit blijven waar ze waren.

Opnieuw verbinden gooit de verbinding weg en bouwt die vanaf het begin opnieuw op, wat adrestoewijzing, route-installatie en elke onderhandeling van de eerste poging herhaalt.

Opnieuw authenticeren herhaalt het identiteitsbewijs zelf, waarbij een inloggegeven, een certificaat of een tweede factor kan horen. Het kan met of zonder opnieuw verbinden gebeuren, afhankelijk van het product.

Wat gebruikers bij vernieuwing merken

Een sleutelverversing hoort bijna onzichtbaar te zijn. Associatie-identificaties veranderen, tellers kunnen worden gereset en applicaties houden hun sockets; een korte pauze in één richting is normaal tijdens de uitwisseling. Een nieuwe identificatie in een statuslijst is geen bewijs van een storing. De logregel na de uitwisseling vertelt je of die klaar is.

Een echte onderbreking bij vernieuwing wijst op iets specifieks. Een mismatch in het voorstel, een verlopen inloggegeven of een padwijziging leveren elk een andere logregel op, en slechts één ervan wordt verholpen door levensduur aan te passen.

Waar de drie in de praktijk uiteenlopen

Is het enige dat verlopen is sleutelmateriaal, ververs dan de sleutel. Zijn het peeradres, de route of de NAT-binding veranderd en komen er geen pakketten meer aan, verbind dan opnieuw. Vraagt de organisatie een periodieke identiteitscontrole, dan is dat opnieuw authenticeren en geen enkele levensduuraanpassing vervangt dat.

De standaardwaarden van protocollen bevatten meestal het juiste antwoord. WireGuard ververst sleutels na een tijd- en datavolumedrempel zonder tussenkomst van de gebruiker; IKEv2-levensduren worden per child-associatie onderhandeld; op TLS gebaseerde tunnels roteren sleutels binnen de bestaande sessie. Levensduren verhogen om een terugkerende fout te vermijden stelt het falen uit en verlengt de blootstelling als een sleutel wordt gecompromitteerd.

Eén voorbehoud is belangrijk voor lange sessies: frequentie alleen schept geen forward secrecy. De eigenschap hangt af van hoe sessiesleutels zich verhouden tot langetermijngeheimen en of oude sleutels worden vernietigd, wat een ontwerp- en implementatievraag is, geen instelling.

Kies standaardwaarden en leg dan de fase vast

Houd de standaardwaarden van de leverancier aan, tenzij een gedocumenteerde eis anders zegt, en wijzig levensduren aan beide kanten als je ze wijzigt. Leg dan vast welke fase elke gebeurtenis bereikte, zodat het volgende geval tegen hetzelfde punt in de handshake kan worden gecontroleerd.

swanctl --list-sas
ip xfrm state | grep -E 'proto|replay-window'
wg show
journalctl -u strongswan --since '1 hour ago' | grep -i -E 'rekey|rekeyed|child'

Voer na een correctie een gecontroleerde vernieuwing uit en stuur verse applicatietraffic door de nieuwe associatie. Een tunnel die meldt dat hij is opgezet maar niets doorstuurt, is het falen dat deze controle moet vangen.