Zum Hauptinhalt springen

2.8. Schlüsselneuaushandlung (Rekeying)

2.8. Schlüsselneuaushandlung (Rekeying)​

Rekeying (Schlüsselneuaushandlung) bedeutet, eine bestehende SA durch eine neue SA zu ersetzen, ohne die Kommunikation zu unterbrechen. Dies geschieht normalerweise, wenn die alte SA bald abläuft. Während des Rekeying MÜSSEN sich beide Seiten auf neues Schlüsselmaterial einigen. Beide Seiten MÜSSEN in der Lage sein, Pakete von der alten und der neuen SA gleichzeitig zu verarbeiten. Abschnitt 2.8 beschreibt das Rekeying für Child-SAs, während Abschnitt 2.18 das Rekeying für die Parent-SA (IKE-SA) beschreibt.

Obwohl Rekeying häufig verwendet wird, ist der zugehörige Austausch nicht zwingend zu implementieren (REQUIRED). Implementierungen mit Rekeying-Funktionalität MÜSSEN den in diesem Dokument beschriebenen CREATE_CHILD_SA-Austausch unterstützen. Implementierungen ohne Rekeying-Funktionalität MÜSSEN im SA-Payload des IKE_SA_INIT-Austauschs lediglich einen Vorschlag senden, der keine rekeying-spezifischen Attribute enthält, damit der Peer kein Rekeying versucht. Implementierungen, die Rekeying nicht unterstützen, MÜSSEN einen CREATE_CHILD_SA-Austausch, der das REKEY_SA-Attribut enthält, ablehnen und eine Antwort mit der Benachrichtigung NO_ADDITIONAL_SAS senden.

Wenn der Initiator ein Rekeying durchführen möchte, initiiert er einen CREATE_CHILD_SA-Austausch mit einem Vorschlag für die neue SA und einschließlich des REKEY_SA-Attributs, das die neu auszuhandelnde SA angibt. Der SPI-Wert im REKEY_SA-Attribut ist der SPI, den die neu auszuhandelnde SA in Senderichtung verwendet. Ein SA-Payload mit dem REKEY_SA-Attribut kann auch verwendet werden, um eine gelöschte SA neu auszuhandeln; in diesem Fall ist der SPI-Wert der Sende-SPI der gelöschten SA. Im CREATE_CHILD_SA-Austausch wird die alte [Ausblend-]SA weiterhin verwendet (d. h., die alte SA wird erst aus der SA-Datenbank (SAD) entfernt, wenn der Rekeying-Austausch abgeschlossen ist), und die neue [Einblend-]SA wird aufgebaut. Der Initiator wird die gerade aufgebaute SA als neue SA verwenden und die alte SA als „tot" markieren (d. h., sie so bald wie möglich löschen). Der Responder markiert die alte SA als „lebend", verwendet aber die neu aufgebaute SA als neue SA. Mit anderen Worten wechseln beide Seiten von der Verwendung der alten SA zur Verwendung der neuen SA, aber der Responder DARF dies erst nach Erhalt einer Bestätigung tun (MUST).

Der aktuelle Inhaber der SA (d. h. die Partei, die im IKE_SA_INIT-Austausch den SA-Vorschlag gesendet hat) MUSS im Rekeying-Austausch der Initiator sein, da die neue SA vom Inhaber vorgeschlagen werden MUSS. Dies vermeidet eine Blockierung gleichzeitiger Rekeying-Austausche. Um eine SA neu auszuhandeln, MUSS der CREATE_CHILD_SA-Austausch vom Inhaber der SA initiiert werden.

Bevor eine Implementierung eine bald zu verwendende SA akzeptiert, kann sie die Bestätigung abwarten, dass die alte SA aus der SAD des Peers entfernt wurde. In diesem Fall MUSS die Implementierung auf die Löschbenachrichtigung in einem INFORMATIONAL-Austausch warten (siehe Abschnitte 2.4 und 3.11). Vor dem Empfang einer solchen Löschbenachrichtigung MUSS die Implementierung die alte SA behalten, da der Peer sie möglicherweise noch verwendet. Dieses Warten ist die Verantwortung sowohl des Initiators als auch des Responders. Implementierungen SOLLTEN die alte SA nicht auf unbestimmte Zeit behalten, MÜSSEN sie aber behalten, bis die Löschbenachrichtigung eintrifft oder die Lebensdauer der SA (bestimmt durch die ausgehandelte Lebensdauer dieser SA) abläuft.

Wenn eine Implementierung mit Rekeying-Funktionalität während des IKE_SA_INIT-Austauschs einen Vorschlag mit dem REKEY_SA-Attribut empfängt, MUSS sie den Vorschlag mit einer Antwort ablehnen, die die Benachrichtigung NO_ADDITIONAL_SAS enthält. Wenn die Implementierung Rekeying nicht unterstützt, MUSS sie einen CREATE_CHILD_SA-Austausch, der das REKEY_SA-Attribut enthält, ablehnen und eine Antwort mit der Benachrichtigung NO_ADDITIONAL_SAS senden. Ein während des IKE_SA_INIT-Austauschs empfangener Vorschlag mit dem REKEY_SA-Attribut ist ein Fehler; ein während eines CREATE_CHILD_SA-Austauschs empfangener Vorschlag mit dem REKEY_SA-Attribut ist jedoch gültig.

Wenn der Rekeying-Austausch fehlschlägt (z. B. wegen NO_ADDITIONAL_SAS oder einem ungültigen Vorschlag), bleibt die alte SA verfügbar, und ein Rekeying kann später versucht werden. Wenn die alte SA abläuft, wird die Kommunikation unterbrochen, und falls die Richtlinien beider Seiten es erlauben, KANN eine neue SA (vielleicht eine ganz neue IKE-SA) aufgebaut werden.

Ressourcenerschöpfung ist ein Denial-of-Service-Angriff, bei dem der Angreifer die Ressourcen des Opfers verbraucht, indem er zu viele SAs anfordert. Um diesen Angriff zu vermeiden, SOLLTEN Implementierungen die Anzahl der zu einem gegebenen Zeitpunkt neu ausgehandelten SAs sowie die Anzahl der von einer einzelnen IKE-SA aufgebauten Child-SAs begrenzen.

2.8.1. Gleichzeitiges Rekeying​

Gleichzeitiges Rekeying liegt vor, wenn beide Peers einen Rekeying-Austausch initiieren. Um eine Blockierung bei gleichzeitigem Auftreten zweier unabhängiger CREATE_CHILD_SA-Austausche zu vermeiden und das mögliche Problem zu umgehen, dass zwei neue SAs inkonsistente IDs aushandeln, MÜSSEN Implementierungen folgende Regeln befolgen:

  1. Der ursprüngliche Inhaber der SA MUSS der Initiator des neuen CREATE_CHILD_SA-Austauschs bleiben.

  2. Wenn der Responder einen CREATE_CHILD_SA-Austausch empfängt, der versucht, eine SA neu auszuhandeln, für die er selbst bereits eine Rekeying-Anfrage gesendet hat, MUSS der Responder der Rekeying-Anfrage des Peers Vorrang vor seiner eigenen geben. In diesem Fall SOLLTE der Responder die von ihm selbst initiierte SA löschen und die vom Peer erzeugte SA verwenden. Der Responder MUSS den neuen SPI an den Initiator senden, damit der Initiator weiß, welchen SPI er verwenden soll.

  3. Zu einem gegebenen Zeitpunkt SOLLTEN nicht mehr als zwei mit derselben ursprünglichen SA verbundene und aktive SAs vorhanden sein.

Um gleichzeitiges Rekeying zu vermeiden, KÖNNEN Implementierungen eine zufällige Zeitspanne warten, bevor sie den Rekeying-Austausch beginnen. Wenn sie eine vom Peer initiierte Rekeying-Anfrage empfangen, während sie ihr eigenes Rekeying noch nicht begonnen haben, SOLLTEN sie der Anfrage des Peers Vorrang vor ihrer eigenen geben.