2.8. Rekeying (Schlüsselerneuerung)
2.8. Rekeying (Schlüsselerneuerung)
IKE-, ESP- und AH-Security Associations verwenden geheime Schlüssel nur für begrenzte Zeit und Datenmenge; das begrenzt die Lebensdauer der SA. Eine abgelaufene SA DARF nicht genutzt werden. Neue SA DÜRFEN bei Bedarf aufgebaut werden. Das Ersetzen abgelaufener SA heißt „rekeying“.
Für minimale IPsec-Implementierungen ist Rekey ohne vollständigen IKE-SA-Neustart optional. Eine Implementierung DARF alle CREATE_CHILD_SA innerhalb einer IKE-SA ablehnen. Läuft eine SA ab oder steht kurz davor und schlägt Rekey fehl, MUSS die Implementierung die IKE-SA und zugehörige Child-SAs schließen und DARF neue starten. Rekey vor Ort verbessert oft Leistung und reduziert Paketverluste.
Child-SA innerhalb bestehender IKE-SA rekeyen: gleichwertige neue SA anlegen (Abschnitt 2.17), alte löschen, sobald die neue steht. Beim Rekey SOLLTE die neue Child-SA nicht andere Traffic Selectors oder Algorithmen haben.
IKE-SA rekeyen: neue gleichwertige IKE-SA per CREATE_CHILD_SA in der bestehenden IKE-SA mit dem Peer der alten IKE-SA aufbauen (Abschnitt 2.18). Sie erbt alle Child-SAs; die neue IKE-SA führt den Steuerdatenverkehr. Danach löscht der Initiator die alte IKE-SA; die Delete-Payload für sich selbst MUSS die letzte Anfrage über die alte IKE-SA sein.
Rekey sollte proaktiv sein: neue SA bevor die alte unbrauchbar wird, mit Puffer zum Umschalten des Datenverkehrs.
IKEv1 verhandelte Lebensdauern; in IKEv2 erzwingt jede Seite ihre eigene Politik. Unterschiedliche Politiken → die Seite mit kürzerer Lebensdauer fordert immer Rekey. Lange inaktive SA: Endstelle DARF bei Ablauf schließen statt rekeyen, oder wenn seit letztem Rekey kein Verkehr war.
IKEv2 erlaubt parallele SA mit gleichen Traffic Selectors (QoS, siehe [DIFFSERVFIELD], [DIFFSERVARCH], [DIFFTUNNEL] Abschnitt 4.1). Anders als IKEv1 identifizieren Endpunkte plus Selectors eine SA nicht immer; die IKEv1-Heuristik, doppelte Selectors zu löschen, SOLLTE nicht verwendet werden.
Bei Paketverlust können Endpunkte den SA-Zustand unterschiedlich sehen. Der Responder auf CREATE_CHILD_SA MUSS Nachrichten auf einer SA akzeptieren, bevor er seine Erstellungsantwort sendet. Der Initiator DARF nach Verarbeitung der Antwort senden, kann aber auf der neuen SA erst nach Empfang und Verarbeitung der CREATE_CHILD_SA-Antwort empfangen. Der Responder DARF nach Senden seiner Antwort senden (interop-korrekt), KANN aber verzögern, um unnötigen Verlust zu vermeiden.
Der Responder weiß, dass der Initiator empfangsbereit ist, wenn (1) er eine kryptographisch gültige Nachricht auf der anderen Hälfte des SA-Paares erhielt oder (2) die neue SA eine bestehende rekeyt und eine IKE-Anfrage die ersetzte SA schließt. Beim Rekey sendet der Responder weiter auf der alten SA, bis eines dieser Ereignisse eintritt. Bei neuer SA KANN er auf eingehende Nachricht oder Timeout warten. Empfängt der Initiator ohne CREATE_CHILD_SA-Antwort, retransmitiert er. Er DARF ein Dummy-ESP-Paket auf neuer leerer ESP-SA senden, um Bereitschaft zu signalisieren.
2.8.1. Simultaneous Child SA Rekeying
Gleiche Lebensdauerpolitik → gleichzeitiges Rekey möglich (redundante SA). Rekey-Anfragen SOLLTEN gejittert werden.
Kurzzeitig mehrere ähnliche SA; ein Knoten MUSS eingehende Pakete über jede zulässige SA akzeptieren. Bei Kollision SOLLTE die SA mit dem kleinsten der vier Nonces vom Ersteller geschlossen werden. „Kleiner“ = Oktett-für-Oktett; endet eine Nonce zuerst, ist sie kleiner. Der Knoten, der die überlebende rekeyte SA initiierte, SOLLTE die alte nach Aufbau der neuen löschen.
Beispiel A und B mit Paar (SPIa1,SPIb1):
Host A Host B
-------------------------------------------------------------------
send req1: N(REKEY_SA,SPIa1),
SA(..,SPIa2,..),Ni1,.. -->
<-- send req2: N(REKEY_SA,SPIb1),
SA(..,SPIb2,..),Ni2
recv req2 <--
A erkennt gleichzeitiges Rekey, weiß aber noch nicht, welches Nonce minimal ist.
send resp2: SA(..,SPIa3,..),
Nr1,.. -->
--> recv req1
B ebenfalls und antwortet.
<-- send resp1: SA(..,SPIb3,..),
Nr2,..
recv resp1 <--
--> recv resp2
Drei Paare existieren. Ist Nr1 in resp2 minimal, löscht B (req2) die redundante neue SA, A die alte.
send req3: D(SPIa1) -->
<-- send req4: D(SPIb2)
--> recv req3
<-- send resp3: D(SPIb1)
recv req4 <--
send resp4: D(SPIa3) -->
Verlust von As erstem req1:
Host A Host B
-------------------------------------------------------------------
send req1: N(REKEY_SA,SPIa1),
SA(..,SPIa2,..),
Ni1,.. --> (lost)
<-- send req2: N(REKEY_SA,SPIb1),
SA(..,SPIb2,..),Ni2
recv req2 <--
send resp2: SA(..,SPIa3,..),
Nr1,.. -->
--> recv resp2
<-- send req3: D(SPIb1)
recv req3 <--
send resp3: D(SPIa1) -->
--> recv resp3
B hält Rekey für beendet, ohne dass A req1 erneut sendet.
resend req1 -->
--> recv req1
B antwortet z. B. mit CHILD_SA_NOT_FOUND.
<-- send resp1: N(CHILD_SA_NOT_FOUND)
recv resp1 <--
A KANN den Fehler ignorieren, wenn gleichzeitiges Rekey bereits bekannt ist.
2.8.2. Simultaneous IKE SA Rekeying
Am komplexesten: gleichzeitiges Rekey der IKE_SA. Abschnitt 2.8 gilt; Child-SAs müssen die richtige IKE_SA erben.
Beide Enden erkennen Gleichzeitigkeit wie bei Child-SA: drei IKE-SAs nach CREATE_CHILD_SA. Die neue IKE-SA mit kleinstem Nonce SOLLTE vom Ersteller gelöscht werden; die andere neue IKE-SA MUSS alle Child-SAs erben.
Sonderfall: Eine Seite beendet, bevor sie die andere bemerkt. Ohne beidseitige Erkennung keine redundanten SA. Die Seite ohne Gleichzeitigkeit, die Rekey einer bereits rekeyten IKE-SA erhält, SOLLTE TEMPORARY_FAILURE senden (IKE-SA wird geschlossen). Erhält die andere Seite Löschung der alten IKE-SA, weiß sie, dass der Peer die Gleichzeitigkeit nicht sah, und KANN den eigenen Rekey-Versuch aufgeben.
Host A Host B
-------------------------------------------------------------------
send req1:
SA(..,SPIa1,..),Ni1,.. -->
<-- send req2: SA(..,SPIb1,..),Ni2,..
--> recv req1
<-- send resp1: SA(..,SPIb2,..),Nr2,..
recv resp1 <--
send req3: D() -->
--> recv req3
B sieht IKE_SA-Schließen und antwortet. B sollte req2 nicht weiter retransmitieren, da A nach resp3 den alten Zustand löscht.
<-- send resp3: ()
TEMPORARY_FAILURE stand nicht in RFC 4306 und wird nicht verhandelt; ältere Peers behandeln es wie unbekannten Fehler und stoppen – ohne Schaden, wenn der andere bereits rekeyed hat.
2.8.3. Rekeying the IKE SA versus Reauthentication
IKE-SA-Rekey und Reauthentifizierung sind unterschiedlich: Rekey neue Schlüssel und Message-ID-Zähler, keine erneute Authentifizierung (keine AUTH/EAP). Reauthentifizierung prüft oft Langzeitidentitäten stärker.
IKEv2 hat kein spezielles Reauth: neue IKE-SA von Grund auf (IKE_SA_INIT/IKE_AUTH ohne REKEY_SA), neue Child-SAs ohne REKEY_SA, alte IKE-SA löschen.
Reauth etabliert ebenfalls neue Schlüssel; „Authentifizierungslebensdauer“ kürzer als „Schlüssellebensdauer“ ist sinnlos.
Neue IKE-SA kann von beiden Seiten der ursprünglichen IKE-SA initiiert werden; EAP/Konfiguration erzwingt praktisch dieselbe Seite wie beim ersten Mal. Der Responder kann Reauth hier nicht anfordern; Erweiterungen wie [REAUTH] existieren.