Mittwoch, 6. Juni 2012


Topthema

Donnerstag, 15. Februar 2007 | Topthema

About Security #93: Virtuelle Private Netze — IKEv2 (3)

(Link zum Artikel: http://www.entwickler.de/php/kolumnen/034320)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

In dieser Folge werden die noch fehlenden Meldungstypen des Internet Key Exchange Protocol (IKEv2, s. RFC 4306) beschrieben: CREATE_CHILD_SA und INFORMATIONAL. CREATE_CHILD_SA wird für Schlüsseländerungen vorhandener CHILD_SA und zur Erstellung zusätzlicher CHILD_SA zu einer gegebenen IKE_SA verwendet. Als Spezialfall ist auch die Änderung der Schlüssel der IKE_SA möglich. INFORMATIONAL wird für den Austausch aller weiteren Nachrichten verwendet, die im Rahmen einer bestehenden IKE_SA anfallen.

N E U ! Security aktuell
Täglich aktuelle Security-Infos!

Die Nachrichten vom Typ CREATE_CHILD_SA und INFORMATIONAL (s.u.) können erst nach dem erfolgreichen Austausch der IKE_SA_INIT- und IKE_AUTH-Nachrichten verwendet werden. Sie werden durch die dabei ausgehandelten Krypto-Algorithmen geschützt, d.h. alle Felder außer dem Header sind verschlüsselt und die gesamte Nachricht einschließlich Header ist integritätsgeschützt.

CREATE_CHILD_SA

Da jeder Kommunikationspartner einen CREATE_CHILD_SA- und INFORMATIONAL-Meldungsaustausch starten kann, bezeichnet Initiator nun den Kommunikationspartner, der diesen Austausch gestartet hat.

 Initiator Responder

HDR, {[N], SA, Ni, [KEi],
[TSi, TSr]} -->
<-- HDR, {SA, Nr, [KEr],
[TSi, TSr]}

{} markiert den verschlüsselten Teil der Nachrichten.

Paket des Initiators
HDR Header des IKE-Protokolls
N Optionale Notify-Payload: Bei einer Schlüsseländerung Spezifikation der betroffenen SA, sonst leer.
SA Angaben über die gewünschten Eigenschaften der SA wie Algorithmen etc.
Ni Vom Initiator zufällig gewählter Nonce-Wert
KEi Optional Diffie-Hellmann-Wert des Initiators, wenn ein erneuter Schlüsselaustausch stattfinden soll
TSi Gewünschte Traffic Selectors auf Seiten des Initiators
TSr Gewünschte Traffic Selectors auf Seiten des Responders

Paket des Responders
HDR Header des IKE-Protokolls
SA Vom Responder aus den Vorschlägen des Initiators ausgewählte Eigenschaften für die SA
Nr Vom Responder zufällig gewählter Nonce-Wert
KEi Ggf. Diffie-Hellmann-Wert des Initiators, wenn ein erneuter Schlüsselaustausch stattfinden soll
TSi Aus den Vorschlägen des Initiators ausgewählte Traffic Selectors auf Seiten des Initiators
TSr Aus den Vorschlägen des Initiators ausgewählte Traffic Selectors auf Seiten des Responders

Wird der CREATE_CHILD_SA-Austausch für eine Schlüsseländerung der IKE_SA verwendet, entfallen die Traffic Selectors.

INFORMATIONAL

Der Meldungstyp INFORMATIONAL wird für den Austausch aller weiteren Nachrichten verwendet, die im Rahmen einer bestehenden IKE_SA anfallen. Dazu gehört insbesondere das Löschen einer SA. Nachrichten, die zu einer bestimmten IKE_SA gehören, müssen unter dieser IKE_SA gesendet werden. Nachrichten zu einer bestimmten CHILD_SA müssen unter der für diese CHILD_SA zuständigen IKE_SA gesendet werden.

 Initiator Responder

HDR, {[N,] [D,] [CP,] ...} -->
<-- HDR, {[N,] [D,] [CP], ...}

{} markiert den verschlüsselten Teil der Nachrichten.

HDR Header des IKE-Protokolls
N Optionale Notification-Payload
D Optionale Delete-Payload
CP Optionale Configuration-Payload

Die Nachrichten enthalten keine bis mehrere Payloads vom Typ Notification, Delete und Configuration. Alle Payloads können auch mehrfach vorkommen. Der Empfänger einer INFORMATIONAL-Nachricht muss darauf antworten, da der Sender sonst davon ausgeht, dass die Nachricht verloren gegangen ist und sie erneut sendet. Die Antwort muss keine Payload enthalten. Eine Anfrage ohne Payload kann zur Erkennung toter Kommunikationspartner verwendet werden.

Löschen einer SA

ESP- und AH-SAs existieren immer paarweise, je eine für aus- und eingehende Pakete. Wird eine SA geschlossen, müssen beide Teile des Paares gelöscht werden. Bei verschachtelten SAs sind ggf. auch mehrere Paare betroffen, die dann gemeinsam gelöscht werden müssen. Dazu muss jeder Kommunikationspartner seine SA für eingehende Pakete löschen und dem anderen Partner zum Löschen dessen zugehöriger SA auffordern. Dafür wird eine INFORMATIONAL-Nachricht mit einer oder mehreren Delete-Payloads verwendet, die die zu schließenden SA spezifizieren. Im Normalfall wird darauf mit einer INFORMATIONAL-Nachricht geantwortet, die Delete-Payloads für die entsprechenden SA der Gegenseite enthält.

About Security: Die komplette Serie

Die einzige Ausnahme entsteht, wenn beide Kommunikationspartner unabhängig voneinander entscheiden, zusammengehörende SAs zu löschen. Da dann beide eine Nachricht mit Delete-Payload senden, die sich bei der Übertragung überschneiden können, wurde folgende Regelung getroffen: Empfängt ein Kommunikationspartner eine Löschungsaufforderung für SAs, für die er selbst bereits eine Löschungsaufforderung gesendet hat, muss er die SA für ausgehende Pakete nach der Auswertung der Aufforderung und die SA für eingehende Pakete nach Absenden der Bestätigung löschen. Dadurch wird verhindert, dass Pakete über eine SA gesendet werden, für die der Kommunikationspartner seine zugehörige SA bereits gelöscht hat. Die Bestätigung darf in diesem Fall keine Delete-Payloads für die gelöschten SAs enthalten, da dies zu einer doppelten Löschungsaufforderung und theoretisch dem Löschen einer falschen SA führt.

Nachdem jetzt alle relevanten Nachrichten beschrieben wurden, folgt in der nächsten Folge ein praktisches Beispiel.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "VPN – Virtuelle Private Netze"

Kommentare

Folgende Links könnten Sie auch interessieren