Nyckelbyte, återanslutning eller reautentisering: vad behöver du?

En session som har kört i timmar behåller inte samma nycklar för alltid, och det är avsiktligt. Tre olika händelser kallas nyckelrotation: nytt sessionsmaterial under en befintlig association, en fullständig ombyggnad av anslutningen och en upprepning av identitetskontrollen. Var och en har olika utlösare, olika kostnad och olika felsignatur. Väljer du fel gör åtgärden antingen ingenting eller tar ner tunneln utan anledning.

Beslutet beror på vilket lager som faktiskt har löpt ut.

Tre operationer som kallas rotation

Ett nyckelbyte skapar färska trafiknycklar inom den befintliga kontrollrelationen, med den mekanism som protokollet definierar. IKEv2 gör det med en ny underordnad säkerhetsassociation, TLS 1.3 med ett nyckeluppdateringsmeddelande och WireGuard med ett nytt handskakning när dess tids- eller meddelandegränser nås. Tunneladresserna och den autentiserade identiteten stannar där de var.

En återanslutning kastar anslutningen och bygger upp den igen från början, vilket upprepar adresstilldelning, ruttinstallation och alla förhandlingar som det första försöket gjorde.

Reautentisering upprepar själva identitetsbeviset, vilket kan innefatta en inloggningsuppgift, ett certifikat eller en andra faktor. Det kan ske med eller utan återanslutning, beroende på produkt.

Vad användarna märker vid förnyelse

Ett nyckelbyte bör vara nästan osynligt. Associationsidentifierare ändras, räknare kan nollställas och applikationer behåller sina sockets; en kort paus i en riktning är normal under utbytet. Ett nytt id i en statuslista är inte bevis på fel. Loggraden som följer utbytet är det som säger om det blev klart.

Ett verkligt avbrott vid förnyelse pekar på något specifikt. Missmatchning i förslaget, en utgången inloggningsuppgift eller en ändrad väg ger var sin annan loggrad, och bara en av dem åtgärdas genom att justera livslängder.

Där de tre går isär i praktiken

Om det enda som löpt ut är nyckelmaterial, byt nyckel. Om peer-adressen, rutten eller NAT-bindningen ändrats och paketen inte längre kommer fram, återanslut. Om organisationen kräver en periodisk identitetskontroll är det reautentisering, och ingen justering av livslängder ersätter den.

Protokollens standardvärden innehåller oftast rätt svar. WireGuard byter nycklar efter en tids- och datamängdströskel utan användaråtgärd; IKEv2-livslängder förhandlas per underordnad association; TLS-baserade tunnlar roterar nycklar inom den befintliga sessionen. Att höja livslängderna för att undvika ett återkommande fel skjuter upp felet och förlänger exponeringen om en nyckel komprometteras.

En reservation är viktig för långa sessioner: enbart frekvens skapar inte forward secrecy. Egenskapen beror på hur sessionsnycklar förhåller sig till långsiktiga hemligheter och om gamla nycklar förstörs, vilket är en design- och implementeringsfråga, inte en inställning.

Välj standardvärden och registrera sedan fasen

Behåll leverantörens standardvärden om inte ett dokumenterat krav säger annat, och ändra livslängder på båda sidor om du ändrar dem alls. Registrera sedan vilken fas varje händelse nådde, så att nästa förekomst kan kontrolleras mot samma punkt i handskakningen.

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'

Efter en rättelse, kör en kontrollerad förnyelse och skicka färsk applikationstrafik genom den nya associationen. En tunnel som rapporterar att den är etablerad men inte vidarebefordrar något är felet som denna kontroll finns för att fånga.