Montag, 4. Juni 2012 |
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.
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.
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!
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 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 |
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.
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.
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.
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!
About Security – Übersicht zum aktuellen Thema "VPN – Virtuelle Private Netze"