Freitag, 31. August 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