IPSec und IKE Eine Einführung

Universität Konstanz Fachbereich Informatik und Informationswissenschaft Protocols that run the internet IPSec und IKE Eine Einführung Richard Wonka 01/423573 Schiffstraße 3 78464 Konstanz richard.wonka@uni-konstanz.de

Inhaltsverzeichnis 1 Wieso IPSec? 2 2 Anwendungen 3 3 Was bietet IPSec? 4 4 Essentielle Bestandteile von IPSec 5 5 Hosts und Gateways 7 6 Ablauf 8 7 Internet Key Exchange (IKE) 9 8 Ausblick 10

Einleitung Nachdem sich die TCP/IP - Protokollfamilie im Internet als Standard etabliert hat, muss sie sich in der enormen weltweiten Verbreitung neuen Herausforderungen stellen. Die Technologie auf der das Internet basiert wurde in freundlicher und vertrauter Umgebung entwickelt. Dabei spielte die Sicherheit eine höchstens untergeordnete, wenn überhaupt eine Rolle. Es wurde kaum daran gedacht, welche Rolle die versandten Daten in einer Informationsgesellschaft für eine breite Öffentlichkeit spielen könnten oder wie ein Missbrauch sich auswirken würde. Die Neuen Herausforderungen an die Kommunikationsplattform Internet stellen sich in Form der Sicherung dieser Kommunikation, die sozial und wirtschaftlich immer relevanter wird. Es gilt also, die Vetraulichkeit, Integrität, Authentizität und Verfügbarkeit der Information, die Kommuniziert werden soll, zu sichern. Die Sicherung der Verfügbarkeit kann durch IPSec nicht geschehen. Die anderen Aspekte der Sicherheit sind die grundlegende Motivation für die Entwicklung von IPSec. Im Folgenden werden also die Begriffe Sicherung und Sicherheit in diesem Kontext benutzt werden. IKE ist eines der von IPSec spezifizierten Schlüsseltauschverfahren, das der Authentifikation und Verschlüsselung der Daten zugrunde liegt. Grundlage dieser Arbeit sind [FRR00] und die einschlägigen von der IETF formulierten RFCs. 1 1 nachzuschlagen unter http://www.ietf.org 1

1 Wieso IPSec? Bei der Betrachtung der Struktur und Funktionsweise des Internet werden wir uns im Folgenden an das TCP/IP-Modell der Beschreibung von Netzwerken halten, wie es z. B. in [Eck03] beschrieben ist. Dieses Modell hat das ISO/OSI Referenzmodell abgelöst, da es der praktischen Umsetzung im Internet näher kommt. Die Sicherung der Kommunikation im Internet oder allgemein der Kommunikation in Netzen kann in verschiedenen Schichten dieses Modells stattfinden, was sich direkt darauf auswirkt, welche Arten von Daten dabei gesichert werden können. Vergleichen wir hierfür die Sicherungsprotokolle GNU Privacy Guard 2 (GnuPG), Secure Socket Layer (SSL) und IP Security (IP- Sec) am Anwendungsbeispiel einer email, um uns zu verdeutlichen, wozu IPSec dient. GnuPG Auf der Anwendungsebene des Schichtenmodells angesiedelt, lässt sich GnuPG - unter anderem - dazu verwenden, den Inhalt von emails zu sichern. Die Header der email bleiben davon aber unberührt, ebenso wie die Übertragung zum empfänger. Um GnuPG zu nutzen, muss der Nutzer die Software auf Seinem System installiert haben und im Idealfall der email-client GnuPG unterstützen. SSL SSL bietet die Möglichkeit, die Übertragung von email zwischen zwei entfernten Rechnern im Netz zu sichern, deren Kommunikation über dieses Netz stattfindet. Die Übermittelten Inhalte sind also undurchsichtig, es können jedoch alle an der kommunitkation beteiligten Router den Informationsfluss nachverfolgen. Die Nutzung von SSL ist nur dann möglich, wenn die beteilgten mailtransport-programme (wie. z. B. exim, qmail oder sendmail) das Protokoll unterstützen. Ein email-client muss nicht notwendigerweise darauf vorbereitet sein. 3 IPSec Auf der Paket-Ebene bietet IPSec die Möglichkeit, die Datenübertragung zwischen zwei beliebigen Knoten im Netz vollständig oder nur Teilweise zu sichern, indem die Inhalte der zu versendenden Pakete 2 http://www.gnupg.de 3 Ein email-client muss nur dann SSL beherrschen, wenn er auch den Transport der Post übernimmt, was aber eigentlich nicht seine Aufgabe ist. 2

wahlweise authentifiziert und/oder verschlüsselt und sogar der Informationsfluss verschleiert werden kann. Das definierende Dokument ist hierbei [KA98a] IPSec setzt bei den Anforderungen an den Nutzer noch weiter unten an, IPSec muss vom Betriebssystem unterstützt sein, das die Netzwerkfunktionalität bereitstellen soll. Die aufsetzende Software muss für die Nutzung von IPSec aber nicht modifiziert werden. 2 Anwendungen Bevor wir uns mit den technischen Details von IPSec und dem darunter liegenden Internet Key Exchange (IKE) auseinandersetzen, wollen wir uns ansehen, wo IPSec zu welchen Zwecken eingesetzt wird und welchen Nutzen wir davon haben. Die größte Anwendung erfährt IPSec derzeit in Wireless LANs (WLAN) und Virtual Private Networks (VPN). Sehen wir zunächst, weshalb IPSec dazu geeignet ist. WLAN Während eine kabelgestützte Kommunikation zwischen Netzwerkknoten noch relativ abgeschlossen ist, muss in wireless LANs die unmittelbare Verbindung zweier Rechner, die geschützt werden. Im Luftraum um die kommunizierenden Partner ist es ohne großen Aufwand möglich, deren Kommunikation zu belauschen oder eigene Signale in die Kommunikation einzuspeisen. Deshalb ist eine Authentifikation der beiden Partner und ihrer Daten notwendig. Handelt es sich um Daten, die vertraulich behandelt werden sollten, muss eine Verschlüsselung stattfinden. Um diese Ziele zu erreichen, ist eine Sicherung auf Paketebene notwendig, da z. B. die anderen oben beschriebenen Sicherungsmethoden auf diese ebene keinen Einfluss haben. VPN Die Verbindung zweier Netzknoten, die nicht direkt miteinander verbunden sind geschieht immer über die dazwischen liegenden Knoten. Diese anderen Knoten gehören mit hoher wahrscheinlichkeit nicht zum Kreis derer, die Zugang zu vertraulicher Information haben sollten. Dennoch setzt die Netzwerkkommunikation voraus, daß die Information die fremden Knoten durchläuft, 3

sie muss also geschützt werden. IPSec kann diesen Schutz bieten und dabei einen Größeren Teil der versandten Information sichern - auch einen Teil der Metainformation wie der Absender- und Empfänger-Adresse, die eventuell auch gesichert werden soll. 3 Was bietet IPSec? Zugriffskontrolle IPSec erlaubt eine Kommunikation nur mit bekannten Kommunikationspartnern, was eine Rudimentäre Zugriffskontrolle erlaubt. Vertraulichkeit... der Inhalte: Die Versandten Daten können durch Verschlüsselungsalgorithmen gegen unautorisierte Einsichtnahme gesichert werden.... des Informationsflusses(beschränkt) Im Tunnel-Modus werden die gesamten Header der Transportierten IP-Pakete von einer weiteren Schicht umschlossen. IPSec kann auf diese Weise deren Inhalte (wie Absender und Empfänger des Paketes) verschleiern Integrität Durch MACs kann festgestellt werden, ob die empfangene Information auf ihrem Weg verändert wurde. Offensichtlich kann eine solche Veränderung dadurch nicht verhindert, wohl aber bemerkt werden. Schutz vor Replay-Attacken IPSec-Pakete werden beim Versand laufend durchnumeriert. Die gegenseite kann (muss aber nicht) dadurch prüfen, ob empfangene Pakete schon einmal empfangen wurden. Sicherheit auf IP-Level Generell können IP-Pakete auf zwei verschiedene Weisen, sogenannte Modi, gesichert werden. Transport-Modus Tunnel-Modus Diese unterscheiden sich funktional vor allem in einem Punkt: Während beide die Sicherheit des Inhalts der Pakete gewährleisten können, kann nur im Tunnel-Modus auch die Metainformation der Header gesichert werden. 4

IP Header IP Header Payload Tr Header* Payload Abbildung 1: Im Transportmodus wird die Payload durch den neu eingefügten Transport-Header geschützt IP Header Payload IP Header* Tu Header* IP Header Payload Abbildung 2: Im Tunnel-Modusl sind auch die IP-Header geschützt Transport-Modus Im Transportmodus wird die des zu sichernden Paketes z. B. durch einen Hash-Algorithmus geschützt. Der daraus gewonnene Wert wird in einem neuen Header-Feld mit dem Paket versandt. Dieses neue Header-Feld wird zwischen die IP-Header und die Payload eingefügt. Tunnel-Modusl Im Tunnel-Modusl wird das gesamte IP-Paket zur Payload eines vollkommen neuen Paketes. Auch hier kann wiederum die Payload (das gesamte zu schützende Paket inclusive der Header-Felder) durch Hashoder Verschlüsselungsalgorithmen gesichert werden und die für die Gegenseite notwendige Information im (neuen) Paket mitgesandt werden. Transport- und Tunnel-Modusl sind in den Abbildungen 1 und 2 allgemein veranschaulicht. 4 Essentielle Bestandteile von IPSec Die Gesamtheit von IPSec ist zusammengesetzt aus einigen Bestandteilen. 5

Security Policy Database (SPD) Anhand der SPD werden alle Pakete überprüft, die den Rechner verlassen. Es wird entschieden, ob und ggf. wie sie durch IPSec behandelt werden sollen, also ob sie IPSec unverändert passieren, verworfen werden, oder welches Protokoll (oder welche Protokolle) in welchem Modus auf die Pakete angewandt werden soll. Security Associations (SA) SA enthalten Informationen über die Sicherheitsdienste, die auf ein Paket angewandt werden sollen: Kommunikationspartner Sender und Empfänger eines Paketes sind darin eindeutig festgelegt. Damit ist eine SA nur für eine Verbindung (unidirektional) anwendbar. Sollen beide Richtungen einer Verbindung gesichert werden, sind somit zwei SA notwendig Protokoll Soll AH oder ESP auf das Paket angewandt werden? IP- Sec unterstützt auch die Anwendung beider Protokolle auf ein Paket, wodurch die Erstellung und Verwaltung zweier SA für eine (unidirektionale) Verbindung notwendig wird. Man spricht hierbei von einem Security Bundle Cryptoalgorithmen und -Schlüssel Welche Algorithmen und ggf. welche Schlüssel sollen auf das Paket angewandt werden? Lebensdauer Die Gültigkeit einer SA ist begrenzt und in der SA selbst vermerkt Security Policy Index (SPI) Die Index-Nummer der SA in SAD. Anhand dieser Nummer verweisen IPSec Pakete auf die SA, die auf sie angewandt werden soll. Die SPI ist hostspezifisch und einmalig. Alle SA sind in der Security Association Database (SAD) verzeichnet. Authentication Header (AH) AH ist eines der Grundlegenden Protokolle von IPSec. Es ermöglicht die Cryptographische Behandlung der Payload von IP-Paketen. AH ist in [KA98b] definiert. 6

IP Header Payload Next Header, Length SPI Seq Nr. HASH (MAC) Abbildung 3: AH im Transportmodus Ein IPSec/AH - Paket unterscheidet sich von IP-Paketen durch ein neues Header-Feld, das zwischen den IP-Headern und der Payload steht. Dies ist eine mögliche Form des Transportmodus, wie oben beschrieben. Abbildung3 zeigt das von IPSec eingefügte Header-Feld im Transportmodus: Nach dem IPHeader wird zunächst Information über das von der IP-Schicht umschlossene Protokoll (Next Header) angefügt. Danach folgt Die Länge des Hash-Wertes, der an das Ende des Neuen Headers angefügt wird. Dazwischen stehen der SPI, mit dem das Paket auf der Empfängerseite assoziiert werden soll und die laufende Nummer des Paketes, um es dem Empfänger zu ermöglichen, Replay-Attacken vorzubeugen. Encapsulating Security Payload (ESP) Während AH nach der IPSec-Spezifikation nur die Integrität der Information sicherstellen können soll, sieht die Spezifikation für ESP auch die Nutzung von Verschlüsselung vor, um die Vertraulichkeit der Daten zu gewährleisten. ESP ist in [KA98c] definiert. Tatsächlich wird bei einem Verzicht auf Verschlüsselung nicht darauf verzichtet, einen Verschlüsselungsalgorithmus anzuwenden, sondern es wird der NULL-Algorithmus [GK98] angewandt, der alle Daten unverändert lässt. Beide Protokolle sind oben im Transport-Modus beschrieben, können aber auch analog zur obigen Erklärung im Tunnel-Modus genutzt werden. 5 Hosts und Gateways Bei den Kommunikationsteilnehmern unterscheidet IPSec zwischen Hosts und (Security-)Gateways. Hosts sind solche Netzknoten, die Endpunkte ei- 7

IP Header Payload(encrypted) SPI Seq Nr. [Init Vector] Pad Next Header ESP Auth Abbildung 4: ESP im Transportmodus ner IPSec-gesicherten Kommunikation sind und keine Kommunikation für andere Knoten absichern. Security-Gateways dagegen nehmen Pakete von anderen Knoten entgegen und leiten diese - durch IPSec gesichert - weiter. Ist einer der beiden Kommunikationspartner ein Gateway, so entfällt die Möglichkeit, den Transport-Modus zu benutzen. Sowohl AH als auch ESP müssen dann im Tunnel-Modusl genutzt werden. 6 Ablauf Die IPSec-gesicherte Kommunikation verläuft wie folgt: Ein übergeordnetes Protokoll übergibt der IPSec-Implementation ein Paket. Anhand der SPD entscheidet IPSec, ob und wie das Paket gesichert werden soll. Nach den Angaben der SAD wird das Paket nach AH und/oder ESP im Transport- und/oder Tunnel-Modusl bearbeitet, mit einer Laufenden Nummer versehen und zum Empfänger gesandt. Dieser prüft zunächst, ob die Absender-Adresse des paketes die eines bekannten kommunikationspartners ist. Ist dem so, entnimmt er nach einer optionalen Prüfung der Sequenznummer dem SPI des Paketes, mit welcher SA das Paket verknüpft ist und Entschlüsselt und/oder Überprüft das Paket mit den angegebenen Schlüsseln und/oder Algorithmen. Ist der Emfänger ein Security-Gateway, so leitet er das paket weiter zum endgültigen Empfänger. Ist er selbst der Enpunkt der Kommunikation, so wird das Paket an die darüberliegende Schicht weitergereicht. 8

7 Internet Key Exchange (IKE) Um eine gesicherte Kommunikation zu ermöglichen, bedarf es geheimer Schlüssel und der verteilung öffentlicher Schlüssel. IPSec sieht auch einen Betriebsmodus mit vorab ausgetauschten Schlüsseln vor, da dies jedoch wenig effizient ist, sind effiziente automatisierte Schlüsseltauschprotokolle in der Spezifikation von IPSec vorgesehen. IKE ist das momentan für IPSec wichtigste Protokoll zum sicheren Tausch und der Generierung geheimer Schlüssel. Es ist ein Hybridprodukt aus Bestandteilen von ISAKMP ([HC98]) OAKLEY ([Orm98]) und SKEME, deren Funktionalität es aber nicht ausschöpft, sondern nur Teile übernimmt und in einen neuen Rahmen fügt. Ablauf Ziel von IKE ist es, die notwendigen Daten zu generieren, um eine oder mehrere SA zur Kommunikation mit dem Gegenüber formulieren zu können. Um dies zu ermöglichen, ist es zunächst notwendig, den Gegenüber zu Authentifizieren. An dieser Stelle bedient sich IKE der für ISAKMP formulierten Authentikation, indem der Initiator der Verbindung (A) Vorschläge für (ISAKMP-)SA 4 an den Antwortenden Knoten (B) sendet. Dieser Gibt an (A) eine für ihn Akzeptable SA zurück. Anhand dieser SA kann nun ein Schlüsseltausch vorgenommen werden. De-facto-Standard ist dabei der Schlüsseltausch nach Diffie-Hellman, wie er z. B. in [RP99] erklärt wird, es können aber auch andere Verfahren eingesetzt werden. Nachdem auf diese Weise die Kommunikation zwischen den Knoten etabliert wurde, können auf die gleiche Weise die SA für IPSec ausgehandelt werden, auf die sich die Pakete dann beziehen können. 4 nicht zu verwechseln mit den IPSec-SAs 9

8 Ausblick IPSec bietet viele Möglichkeiten, die Sicherung der IP-Ebene auf die Persönlichen anforderungen anzupassen, darunter auch einige Redundanzen. Die Komplexität des Protokolls oder - besser - der Protokollsammlung bietet zwar einiges an Funktionalität, ist aber gerade im Bereich der Sicherheit problematisch, wie Ferguson und Schneier in [SF] bemerken. Da IPSec bereits als fester Bestandteil von IPv6 geplant ist, ist seine baldige und weitläufige Verbreitung wohl nicht in Frage zu stellen, doch zeigen sich noch Probleme an einigen Stellen. Beispielsweise gibt es keine klare Regelung, wie die Länge der Pakete gehandhabt werden soll, wenn sie durch den Einsatz von IPSec die für IP-Pakete maximale Länge überschreitet. Bisherige Implementationen von IPSec finden hierfür nur wenig elegante Lösungen. Ist IPSec jedoch fehlerfrei konfiguriert, so bietet es alle MÖglichkeiten der Sicherung, die auf der Paket-Ebene erwartet werden können und kann - und wird vermutlich - der Sicherung verschiedenster Netzdienste dienlich sein. 10

Index AH, 6, 8 ESP, 6 8 Gateway, 7 GnuPG, 2 Header, 5 Host, 7 IKE, 3, 9 IP, 1 IPSec, 2 IPv6, 10 ISAKMP, 9 ISO/OSI, 2 MAC, 4 OAKLEY, 9 Payload, 5 SA, 6, 8, 9 SAD, 6 Security Bundle, 6 SKEME, 9 SPD, 6, 8 SPI, 6 8 SSL, 2 TCP, 1 Transport-Modus, 5, 7 Tunnel-Modus, 4, 7 VPN, 3 WLAN, 3 11

Literatur [Atk95a] Atkinson, R.: RFC 1825: Security Architecture for the Internet Protocol, August 1995. Obsoleted by RFC2401 [KA98a]. Status: PROPOSED STANDARD. [Atk95b] Atkinson, R.: RFC 1826: IP Authentication Header, August 1995. Obsoleted by RFC2402 [KA98b]. Status: PROPOSED STANDARD. [Atk95c] Atkinson, R.: RFC 1827: IP Encapsulating Security Payload (ESP), August 1995. Obsoleted by RFC2406 [KA98c]. Status: PROPOSED STANDARD. [Eck03] Eckert, Claudia: IT-Sicherheit. Oldenbourg Wissenschaftsverlag, München, Wien, 2003. [FRR00] Fischer, Stephan, Christoph Rensing und Utz Rödig: Open Internet Security. Springer-Verlag, 2000. [GK98] [HC98] Glenn, R. und S. Kent: RFC 2410: The NULL Encryption Algorithm and Its Use With IPsec, November 1998. Status: PROPO- SED STANDARD. Harkins, D. und D. Carrel: RFC 2409: The Internet Key Exchange (IKE), November 1998. Status: PROPOSED STANDARD. [KA98a] Kent, S. und R. Atkinson: RFC 2401: Security Architecture for the Internet Protocol, November 1998. Obsoletes RFC1825 [Atk95a]. Status: PROPOSED STANDARD. [KA98b] Kent, S. und R. Atkinson: RFC 2402: IP Authentication Header, November 1998. Obsoletes RFC1826 [Atk95b]. Status: PRO- POSED STANDARD. [KA98c] Kent, S. und R. Atkinson: RFC 2406: IP Encapsulating Security Payload (ESP), November 1998. Obsoletes RFC1827 [Atk95c]. Status: PROPOSED STANDARD. [Orm98] Orman, H.: RFC 2412: The OAKLEY Key Determination Protocol, November 1998. Status: INFORMATIONAL. [RP99] Rechenberg, Peter und Gustav Pomberger (Herausgeber): Informatik-Handbuch. Carl Hanser Verlag, 2. Auflage, 1999. 12

[SF] Schneier, Bruce und Niels Ferguson: A Cryptographic Evaluation of IPSec. 13