Zusammenfassung und Ergänzung zum Vortrag IKEv1 vs. v2 Wie verändert die Version 2 von IKE das Verhalten? Von Monika Roßmanith (CNB) und Simon Rich (CN) Somersemester 2008 Vorlesung: Netzwerksicherheit Fachbereich: Informatik Studiengang: Computer-Networking (-Bachelor)
Inhaltsverzeichniss Einführung... 3 IPSec... 3 Encapsulating Security Payload (ESP)... 3 Authentification Header (AH)... 3 Transport Mode Tunnel Mode... 3 Security Association (SA)... 4 Security Policy Database (SPD)... 4 Perfect Forward Secrecy... 4 IKE... 5 IKE Phase 1... 5 IKE Phase 2... 5 IKEv1... 5 IKEv2... 6 Zusammenfassung der Unterschiede... 6 Quellen... 7 2
Einführung In dieser Zusammenfassung soll zuerst eine grober Überblick über IPSec und die verwendeten Terminologien gegeben werden. Anschließend wird das Protokoll IKEv1 und IKEv2 in detaillierter Form vorgestellt und die Arbeitsweise erklärt. Im letzten Teil werden dann die Unterschiede zwischen den beiden Versionen von IKE dargestellt. Im Anhang befindet sich dann noch das Quellenverzeichnis. IPSec Bei IPSec handelt es sich um eine Sicherheitsarchitektur die für IPv6 entwickelt wurde um die Sicherheitslücken des Internet Protokolls zu beheben. Es soll Authentizität, Vertraulichkeit und Integrität gewährleisten. IPSec unterstützt 3 Verschlüsselungsszenarien: Host-zu-Host, Host-zu-Security-Gateway und Security-Gateway-zu- Security-Gateway. Um diese zu realisieren enthält IPSec die Protokolle AH und ESP, sowie eine Schlüsselverwaltung, die durch IKE realisiert wird. Des Weiteren stehen 2 Modi zur Verfügung um diese Protokolle zu betreiben: Tunnelmodus und Transportmodus. Encapsulating Security Payload (ESP) Durch ESP wird die Vertraulichkeit der Daten oder die Authentizität der (gekapselten Daten, aber nicht die des Headers) sichergestellt. ESP wird im Next-Header Feld des vorherigen Headers mit 50 angegeben. ESP schließt die authentifizierten bzw. verschlüsselten Daten des IP-Payloads in einem Header und Trailer ein. Um einen möglichst großen Bereich zu schützen, sollte der ESP-Header möglichst weit vorne im IP-Paket angeordnet sein. Allerdings dürfen keine Informationen verschlüsselt werden die für den Transport des Pakets notwendig sind. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ---- Security Parameters Index (SPI) ^Auth. Cov- Sequence Number erage ---- Payload Data* (variable) ^ ~ ~ Conf. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cov- Padding (0-255 bytes) erage* +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pad Length Next Header v v ------ Authentication Data (variable) ~ ~ [2406] Abschnitt 2 Authentification Header (AH) Der AH ist ein Protokollheader mit der Protokollnummer 51. Er beinhaltet eine digitale Signatur sowohl der enthaltenen Nutzdaten als auch eines Teils des äußeren IP-Headers. Dies hilft die Authentizität des Absenders und die Integrität der übermittelten Informationen sicherzustellen. Außerdem enthält er zur Verhinderung von Replay-Attacken eine Sequenznummer. Der Empfängerhost oder -gateway kann anhand der Sequenznummer feststellen, ob das Paket schon einmal empfangen wurde, und es gegebenenfalls verwerfen. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Next Header Payload Len RESERVED Security Parameters Index (SPI) Sequence Number Field + Authentication Data (variable) [2402] Abschnitt 2 Transport Mode Tunnel Mode Der Transport Modus wird nur für Verbindungen von Endpunkt zu Endpunkt genutzt. AH oder ESP transportieren die Daten von z.b. TCP entweder authentifiziert (mit Hilfe des AH), verschlüsselt (mit Hilfe von ESP) oder beides (mit Hilfe von ESP oder einer Kombination von AH und ESP). Die Endpunkt zu Endpunkt Nutzung von IPSec ist die einzige Einsatzmöglichkeit des Transport Mode. Für Endpunkt zu Endpunkt Nutzung könnte auch der Tunnel Mode verwendet werden, mit dem Nachteil das der IP-Header ein redundantes mal, in verschlüsselter Form, übertragen wird. Aus diesem Grund wurde schon vorgeschlagen den überflüssigen Transport Mode abzuschaffen. [ferg] Seite 6; 3
Der Tunnel Modus kann für verschiedene Szenarien verwendet werden: - Endpunkt zu Endpunkt - Endpunkt zu Security Gateway (SG), z.b. als Remote-Access für Aussendienstmitarbeiter - SG zu SG, z.b. um Niederlassungen in ein Firmennetzwerk zu integrieren Der Tunnel Modus kann ebenfalls wieder auf verschiedene Arten realisiert werden. Authentifiziert (mit Hilfe des AH), verschlüsselt (mit Hilfe von ESP) oder beides (mit Hilfe von ESP oder einer Kombination von AH und ESP). In beiden Modi, Tunnel und Transport (von dem der Transport Modus als nahezu überflüssig betrachtet werden kann), stehen auch noch weitere Varianten mit Hilfe von AH und ESP zur Verfügung. Dies erhöht die Komplexität der IPSec- Architektur unnötig, daher wurde vorgeschlagen das AH-Protokoll komplett aus IPSec zu entfernen. [ferg] Seite 8; Folgendes Bild soll die verschieden Möglichkeiten, von Tunnel und Transport Modusm jeweils einmal realisiert durch AH und einmal durch ESP, verdeutlichen: [Bild: http://www.tech-invite.com/security/ti-ipsec-modes.pdf Seite 2] Security Association (SA) Eine SA besitzt eine Unidirektionale Gültigkeit, bis auf die initialen ISAKMP-SA s, diese sind bidirektional. In ihr werden die zwischen den Instanzen ausgehandelten Verfahren in Bezug auf Verschlüsselung und Authentifikation sowie Lebensdauer der Schlüssel, Angaben über kryptographischen Synchronisation bzw. den Initialisierungsvektor und die IP des Endsystems festgehalten. SA s werden aus der IP-Adresse des Endpunktes und der SPI ermittelt. Die SA s werden in einer Security Assosiation Database (SAD) verwaltet. Am Ende einer Verbindung werden alle SA s und deren abgeleiteten Child-SA s in der SAD gelöscht. Security Policy Database (SPD) Ähnlich eines Paketfilters, wird in IPSec jedes Paket, nach Filterregeln bearbeitet. Diese Filterregeln, so genannte Selektoren, werden in der SPD gespeichert. Für jedes ein oder ausgehende Paket werden die Regeln in der SPD der Reihen nach anhand der Selektoren überprüft, ob sie zu diesem Packet passen. Bei der ersten Übereinstimmung wird das Paket diesen Regeln entsprechend bearbeitet. So sind Adress und / oder Dienst-Filterungen möglich. Diese Selektron enthalten neben möglichen Aktionen ( apply IPSec, bypass IPSec, discard) auch Kriterien wie das zu verwendende IPSec-Protokoll, IPSec-Modus, Auth- und Krypt-Verfahren und auch einen Zeiger auf die Zugehörige SA. Perfect Forward Secrecy Mit Perfect Forward Security (PFS) ist gemeint das die Kompromittierung eines einzelnen Schlüssels nur den Zugriff auf Daten erlaubt, die von diesem einzelnen Schlüssel geschützt sind. Damit PFS funktioniert, darf z.b. der Schlüssel der die Übertragung schütz, nicht zum herleiten weiterer Schlüssel verwendet werden. Wenn der Schlüssel, für den Schutz der Übertragung, von anderem Schlüsselmaterial abgeleitet wurde, darf dieses Schlüsselmaterial nicht zur Ableitung weiter Schlüssel verwendet werden. [2409] Abschnitt 3.3; IKE (v1 und v2) stellt PFS für Schlüssel und Identitäten bereit. [2409] Abschnitt 8; 4
IKE Das IKE-Protokoll ist ein Protokoll zur Realisierung von Sicherheitsbeziehungen und zum Verhandeln und Austauschen von authentifiziertem Schlüsselmaterial. Das IKE-Protokoll benutzt in seiner Grundlage drei Prokolle, das Internet Security Association Key Managment Protocol (ISAKMP), Oakley und wenige teile von SKEME. ISAKMP bietet eine Umgebung für Authentifizierung und krypthographischen Schlüsselaustausch, gibt allerdings keine Vorgaben bezüglich dieser vor. Das IKE-Protokoll wurde so konzipiert, dass es unabhängig von Verbindungsprotkollen ist, d.h. dass es in einer Vielzahl vonn Schlüsselaustauschszenarien eingesetzt werden kann. ISAKMP ist unabhängig von Schlüsselaustauschverfahren und ist vor allem für die Verhandlungen der Parameter und Mechanismen zuständig. Oakley beschreibt eine Reihe von Schlüsselaustauschverfahren und unterteilt diese entsprechend dem angestrebten Ziel (z.b. Perfect Forward Secrecy für Schlüssel oder Schutz der Identität und Authentifizierung. Während sich Oakley in Modi gliedert, arbeitet ISAKMP in Phasen. [kuts] Kapitel 3 IKE Phase 1 Die erste Phase wird genutzt um mit Hilfe eines Diffie-Hellman-Verfahrens und dem Austausch von SAs eine erste verschlüsselte und authentifizierte Verbindung zu erhalten, diese initiale ISAKMP-SAs, ist die einzige bidirektionale SA in einer Verbindung. Diese ISAKMP-SA bleibt bis zum Ende der IPSec-Verbindung bestehen, da die Child-SAs ebenfalls gelöscht würde, wenn man die ISAKMP-SA löscht. IKE Phase 2 In diesem so genannten Quick Mode werden weiter SAs mit dem Kommunikationspartner aufgebaut, wieder mit einem Diffie-Hellman-Verfahren um die PFS zu gewährleisten. Dieser Mode wird immer wieder, während des bestehens einer IPSec-Verbindung, genutzt sei es zum Aufbau von Protokoll-SAs (z.b. AH, ESP) oder zum Austausch von neuem Schlüsselmaterial, wenn das alte abgelaufen ist. IKEv1 Im Folgenden werden wir auf die Details in IKEv1 eingehen. In der Phase 1 besteht die Möglichkeit aus vier verschiedenen Authentifizierungsverfahren für den initialen Schlüsselaustausch zu wählen: - Signaturen - Public Key Encryption - Revised Public Key Encryption - Pre-Shared Keys Des Weiteren kann innerhalb jedes dieser Verfahren zwischen zwei weiteren, unterschiedlichen Modes gewählt werden. Das ist zum einen der Main Mode, der in den folgenden 3 Schritten (mit je 2 Nachrichten) abläuft: 1. Aushandeln der Verfahrensweise (Policy) 2. Austausch der Diffie-Hellman-Schlüsselkomponenten und für den Austausch zusätzlich benötigte Daten (z.b. Nonces, zahlen die nur einmal benutzt werden um z.b. Replay Angriffe erkennen zu können) 3. Authentifizierung des Diffie-Hellman-Schlüsselaustausch (Hierfür wird eins der zuvor vier aufgelisteten Verfahren benötigt) Der Aggressive Mode ist ähnlich wie der Main Mode aufgebaut, aber abgekürzt auf nur drei Nachrichten: 1. Der Anfragende (Alice) schlägt alle seine unterstützen Verfahrensweisen (Policys) vor, zusammen mit allen benötigten Daten für den Schlüsselaustausch (inkl. Diffie-Hellman-Information). 2. Der Angefragte (Bob) wählt eine Verfahrensweise aus und schickt diese zusammen mit alle benötigten Information. 3. Der Anfragende (Alice) authentifiziert seinerseits die bisherigen Session-Parameter in der dritten Nachricht an den Angefragten (Bob). Nach Abschluss eines dieser, insgesamt acht Verfahren, ist die Phase 1 beendet. Die Phase 2 nutzt, die in Phase 1 ausgehandelten, Verschlüsselungen und Authentifizierungsverfahren um die Kommunikation der 2 Phase zu schützen und zu authentifizieren. Hier in der 2 Phase werden nun Schlüssel und andere benötigte Daten, für die Verschlüsselung und Authentifizierung der eigentlichen Datenleitungen, ausgehandelt. Der Quick Mode besteht aus den folgenden drei Nachrichten: 1. Diffie-Hellman-Schlüsselmaterial wird an den Angerufenen (Bob) versendet (alternativ, Shared-Key Generierungsmechanismus, dieser bietet allerdings keine PFS). 2. Der Angerufene (Bob) antwortet mit Schlüsselmaterial und den restlichen benötigten Daten. 3. Das erfolgreiche empfangen des Schlüsselmaterials wird dem Angerufenen (Bob) durch eine Conf-Nachricht vom Anrufer (Alice) bestätigt. Der Quick Mode in Phase 2 ist für alle acht möglichen unterschiedlichen Phase 1 Verfahren gleich. 5
IKEv2 In IKEv2 ist die Phase 1 nochmals aufgeteilt in IKE_SA_INIT und IKE_AUTH, jeweils mit zwei Nachrichten. Durch den Einsatz von IKE_AUTH mit EAP sind es in IKE_AUTH mehr wie zwei Nachrichten. 1. IKE_SA_INIT ist für den Austausch von SA s, Diffie-Hellman-Schlüsselmaterial und den Nonces. 2. IKE_AUTH dient dazu die ersten beiden Nachrichten zu Authentifizieren, die Identitätsinformationen auszutauschen und die erste CHILDE_SA zu erzeugen. Die Payloads des IKE_AUTH sind verschlüsselt und authentifiziert, mit Hilfe der Schlüssel, die in der IKE_SA_INIT ausgetauscht wurden. Die Phase 2 in IKEv2 besteht aus dem CREATE_CHILD_SA-Austausch, in diesem Teil sind alle Nachrichten Verschlüsselt. 1. Der Anrufende (Alice) sendet eine CREATE_CHILD_SA-Anfrage, diese enthält alles benötigten Informationen z.b. SA, Traffic Selector für beide Seiten, optional mit neuem Diffie-Hellman-Schlüsselmaterial, zu Gewährleistung der PFS. 2. Der Angerufene (Bob) Antwortet mit allen benötigten Informationen (SA, TS und evtl. optionale Payloads). Es gibt in IKEv2 noch weiter Typen für den Nachrichtenaustausch: CREATE_CHILD_SA mit Schlüsselaktualisierung (optional wieder mit neuen Diffie-Hellman-Schlüsselmaterial) INFORMATIONAL Austausch, mit dieser Payload können unterschiedliche Fehler erkannt werden. Über den INFORMATIONAL Typ wird auch das beenden einer Verbindung dem Gegenüber mitgeteilt. IKE_AUTH mit EAP (Extensible Authentication Protocol) ermöglich das flexible nutzen von Authentifikationsmechanismen, z.b. für IEEE802.1x. Zusammenfassung der Unterschiede IKEv2 ist in einem einzigen RFC Dokument (RFC4306) spezifiziert im Gegensatz zu IKEv1, dies wurde in 3 RFCs spezifiziert (RFC2407, RFC2408, RFC2409). Zusätzlich wurden die Unterstützung von NAT Traversal, Extensible Authentication und Remote Address hinzugefügt die zuvor nur durch proprietäre oder RFC-Draft Erweiterungen möglich waren. Da die Komplexität des Protokolls bzw. der gesamten Architektur von IPSec immer wieder als der Hauptkritikpunkt aufgeführt wurde, sollte diese Vereinfachung und Klarstellung zum Abbau der Komplexität dienen. [ferg] Abschnitt 2.1; [ieee]; Zur weitern Vereinfachung wurden die 8 verschieden initialen Austauschverfahren durch einen 4 Nachrichten umfassenden Austausch ersetzt. Diese vereinfacht vor allem den Aufbau von ISAKMP SAs, die in der ersten Phase von IKE ausgetauscht werden. Ohne einen erfolgreichen Austausch von ISAKMP SAs können keine IPSec-Verbindungen aufgebaut werden. Die "Domain of Interpertation", "Situation" und "Labeled Domain Identifier" wurden entfernt. Um die die Latenz von IKEv2 zu verringern wurde das initale Austauschverfahren auf 2 round-trips (4 Nachrichten) verkürzt. Dies wurde durch hinzufügen der Fähigkeit, Nachrichten zusammen zu packen (piggyback), ermöglich. Um die Implementierung des Protokolls weiter zu vereinfachen und sicherheitstechnische Analysen leichter durchführen zu können wurde die kryptographische Syntax, um die IKE-Nachrichten zu verschlüsseln, ersetz. Diese ist, mit kleinen Änderungen, basiert auf der von ESP. Um die Anzahl der möglichen Fehlerzustände zu verringern wurde das Protokoll zuverlässig (alle Nachrichten werden bestätigt) und Seqenznummern wurden eingeführt. Dies erlaubt den CREATE_CHILD_SA Nachrichtenaustausch von 3 auf 2 Nachrichten zu verkürzen Um die Robustheit zu verbessern (vor allem gegenüber DoS-Angriffen), muss in IKEv2 der Angefragte (Bob), keine ausschlaggebende Bearbeitungszeit mehr für das Verarbeiten von Anfragen aufwenden und auch keine Zustände mehr speichern, bis zu dem Zeitpunkt an dem klar ist das der Anfragende (Alice), Nachrichten an der angegebenen IP-Adresse empfangen kann und dieser sich kryptographisch Authentifiziert hat. Kryptographische Schwächen, wie z.b. die Symmetrie in Hashes für die Authetifizierung, wurden ausgebessert Um "Traffic Selectors" flexibler zu gestalten wurde ein eigener Payload-Typ eingeführt. So muss die ID-Payload nicht überladen werden, wie es in IKEv1 der Fall war. So können Parameter für die Filterung des IPSec- Verkehrs einfacher Übergeben werden. Das benötigte Verhalten unter bestimmten Fehlerbedingungen oder wenn unverständliche Daten erhalten wurden, wurde spezifiziert. Dies war nötig um die Entwicklung zukünftiger Versionen zu vereinfachen ohne die Abwärtskompatibilität unmöglich zu machen. Zu Vereinfachung und Klarstellung wurde der gemeinsame State im Fehlerfall oder bei DoS-Angriffen definiert. U.a. ist so ein totes Gegenüber deutlicher einfacher zu erkennen, die zur Verbindung gehörenden SAs können gelöscht werden und ein Neustart des Protokollablaufs wird schneller eingeleitet. Um den Portierungsaufwand bei alten IKEv1 Implementierungen auf IKEv2 so einfach wie möglich zu halten wurden bestehende Syntax und die Magic Numbers erweitert. [4306] Anhang A; 6
Quellen [2402] S. Kent, R. Atkinson, "IP Authentication Header"; RFC 2402, Nov 1998, http://tools.ietf.org/rfc/rfc2402.txt [2406] S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)"; RFC 2406, Nov 1998, http://tools.ietf.org/rfc/rfc2406.txt [2407] D. Piper, "The Internet IP Security Domain of Interpretation for ISAKMP"; RFC 2407, Nov 1998, http://tools.ietf.org/rfc/rfc2407.txt [2408] D. Maughan, M. Schertler, M. Schneider, J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)"; RFC 2408, Nov 1998, http://tools.ietf.org/rfc/rfc2408.txt [2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)"; RFC 2409, Nov 1998, http://tools.ietf.org/rfc/rfc2409.txt [4306] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol"; RFC 4306, Dez 2005, http://tools.ietf.org/rfc/rfc4306.txt [4308] P. Hoffman, "Cryptographic Suites for IPsec"; RFC 4308, Dez 2005, http://tools.ietf.org/rfc/rfc4308.txt [4718] P. Eronen, P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines"; RFC 4718, Okt 2006, http://tools.ietf.org/rfc/rfc4718.txt [para] [regi] [sous] [huss] [ferg] "IKEv2 Parameters - per [RFC4306]"; http://www.iana.org/assignments/ikev2-parameters "Internet Key Exchange (IKE) Attributes - per RFC 2409 (IKE)"; http://www.iana.org/assignments/ipsecregistry H. Soussi, M. Hussain, H. Afifi, D. Seret, "IKEv1 and IKEv2: A Quantitative Analyses"; http://www.mathinfo.univ-paris5.fr/~seret/paperb4f.pdf M. Hussain, I. Hajjeh H. Afifi, D. Seret, "Tri-party IKEv2 in Home Networks"; http://www.math-info.univparis5.fr/~seret/ikev2-triparty-mhn.pdf N. Ferguson, B. Schneier "A Cryptographic Evaluation of IPSec"; http://www.schneier.com/paperipsec.html [ieee] R. Perlman, C. Kaufmann, "Key Exchange in IPSec: Analysis of IKE"; IEEE Internet Computing, Vol. 4 Issue: 6, Nov-Dez 2000, http://ieeexplore.ieee.org/iel5/4236/19367/00895016.pdf?tp=&isnumber=&arnumber=895016 [stef] [rich] [kuts] [ecke] A. Steffen, "Leichter tunneln - IPSec-VPNs werden einfacher und flexibler dank IKEv2"; http://www.heise.de/security/einfacher-vpn-tunnelbau-dank-ikev2--/artikel/102744 M. Richter, "IPSec - Grundlagen"; http://www.sec.informatik.tu-darmstadt.de/pages/lehre/ws02-03/seminar/ausarbeitungen/ipseci.pdf R. Kutsch, "Internet Key Exchange"; http://krypt.cs.unisb.de/teaching/seminars/ws2001/final/writeups/9.pdf C. Eckert, "IT-Sicherheit: Konzepte Verfahren - Protokolle"; Oldenbourg Wissenschaftsverlg [bles] R. Bless, E. Blaß, M. Conrad, H. Hof, K. Kutzner, S. Mink, M. Schölle, "Sichere Netzwerkkommunikation: Grundlagen, Protokolle und Architekturen"; Springer Verlag [gema] Gematik Gesellschaft für Telematikanwendungen der Gesundheitskarte mbh"einführung der Gesundheitskarte - Netzwerkspezifikation"; http://www.dimdi.de/dynamic/de/ehealth/karte/downloadcenter/technik/kartenspezifikation/spez_testphase_ar chiv/spez_testphase_archiv_5_netz/netzwerkspezifikation_v1-0-0.pdf 7