Montag, 4. Juni 2012


Topthema

Donnerstag, 1. Februar 2007 | Topthema

About Security #91: Virtuelle Private Netze — IKEv2 (1)

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

Das Internet Key Exchange Protocol (IKEv2) wird von IPsec für den Schlüsselaustausch verwendet. IKEv2 wurde im Dezember 2005 in RFC 4306 standardisiert und soll einige Schwachstellen bzw. Probleme seines Vorgängers IKE korrigieren. So wurde die gesamte Definition, die bei IKE noch auf mehrere Dokumente verteilt war, in einem Dokument zusammengefasst. Der Verbindungsaufbau wurde vereinfacht, statt neun gibt es nur noch vier IKE-Meldungen. Insgesamt ist IKEv2 weniger komplex als sein Vorgänger, was die Implementierung erleichtert und die Sicherheit erhöht. Außerdem gibt es viele Verbesserungen, allerdings auch den Nachteil, dass IKEv2 nicht abwärtskompatibel zu IKE ist. Die Header ähneln sich jedoch weit genug, um beide Protokolle über denselben UDP-Port betreiben zu können.

Aufgaben von IKE/IKEv2

Bevor die geschützte Kommunikation über eine IPsec-Verbindung möglich ist, müssen sich die Kommunikationspartner über die zu verwendenden kryptographischen Algorithmen und Schlüssel einigen. Diese Parameter werden (wie in About Security #90 beschrieben) in einer Sicherheitsassoziation (SA) gespeichert. IKE/IKEv2 dient der automatischen Aushandlung und Verwaltung der Sicherheitsassoziationen. In IKEv2 wird dabei zwischen zwei Typen von SA unterschieden: Die von IKE für die Aushandlung der eigentlichen Kommunikationsparameter verwendeten IKE_SA und die diesen zugeordneten CHILD_SA mit den jeweils individuell ausgehandelten Kommunikationsparametern.

Rollen in IKEv2

Ein wichtiger Punkt in der IKEv2-Terminologie sind die verteilten Rollen: Der Kommunikationspartner, der einen Meldungsaustausch initiiert, wird als Initiator bezeichnet. Der auf die Initialisierung antwortende Kommunikationspartner wird als Responder bezeichnet. Im globalen Kontext wird der Initiator der Kommunikationspartner, der die IKE_SA initiiert hat, machmal auch als 'Original Initiator' bezeichnet. Beim ersten Meldungsaustausch sind Initiator und 'Original Initiator' identisch, sodass zur Vereinfachung auf das 'Original' meist verzichtet wird.

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

Meldungstypen

IKEv2 definiert vier Meldungstypen: IKE_SA_INIT für die Initialisierung einer IPsec-Verbindung, IKE_AUTH für die Authentifizierung der Kommunikationspartner, CREATE_CHILD_SA für Schlüsseländerungen und die Erstellung zusätzlicher CHILD_SA sowie INFORMATIONAL für den weiteren Informationsaustausch.

IKE_SA_INIT

IKE_SA_INIT startet die (unverschlüsselte) Initialisierung einer IPsec-Verbindung. Dabei werden die verwendeten Algorithmen ausgehandelt und die zu verwendenden Schlüssel über einen Diffie-Hellmann-Schlüsselaustausch (dazu in einer künftigen Folge mehr) ausgetauscht.

 Initiator Responder

HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]

Paket des Initiators
HDR Header des IKE-Protokolls
SAi1 Vorschläge (Proposals) für die zu verwendenden kryptographischen Algorithmen
KEi Öffentlicher Diffie-Hellmann-Wert des Initiators
Ni Vom Initiator zufällig gewählter Nonce-Wert (wird später als Eingabewert für krypographische Funktionen verwendet)

Paket des Responders
HDR Header des IKE-Protokolls
SAr1 Aus den Vorschlägen des Initiators ausgewählte kryptographische Algorithmen
KEr Öffentlicher Diffie-Hellmann-Wert des Responders
Nr Vom Responder zufällig gewählter Nonce-Wert
CertReq Optionale Anforderung eines Zertifikats, das der Initiator in der nächsten Meldung verwenden soll
Erfolgreicher Austausch

Im Idealfall reicht je eine Request- und Response-Nachricht aus. Gibt es Unstimmigkeiten über die zu verwendenden Algorithmen oder gehen Nachrichten verloren, können jedoch tatsächlich mehrere Nachrichten notwendig sein.

About Security: Die komplette Serie

Geht eine Request- und Response-Nachricht verloren, sendet der Initiator nach Ablauf eines bestimmten Timeout-Werts seinen Request erneut. Der Responder weiß, ob er diesen Request bereits beantwortet hat und antwortet entweder mit der zu diesem Request gehörenden Response oder einer neu erstellten.

Nicht erfolgreicher Austausch

Der Initiator schlägt die zu verwendenden Algorithmen vor. Kann der Responder aufgrund seiner lokalen Policy keinen der vorgeschlagenen Algorithmen akzeptieren oder lehnt er die Initialisierung aus anderen Gründen ab, antwortet er mit einer IKE_SA_INIT-Response mit einer so genannten Notify Payload. Diese enthält einen spezifischen Fehlercode, auf den der Initiator dann reagieren kann.

Verhinderung von Denial-of-Service-Angriffen

Um Denial-of-Service-Angriffe durch eine Vielzahl von IKE_SA_INIT-Requests mit gefälschten Senderadressen zu verhindern, kommen Cookies zum Einsatz. Der Responder antwortet auf den IKE_SA_INIT-Request mit einem IKE_SA_INIT-Response mit Cookie, der Initiator muss danach seinen IKE_SA_INIT-Request unter Einbeziehung des Cookies erneut senden.

In der nächsten Folge wird die Beschreibung von IKEv2 mit der IKE_Auth-Meldung fortgesetzt.

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