IPSec und IKE - Fachbereich Informatik und Informationswissenschaft

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
[email protected]
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 Guard2 (GnuPG), Secure Socket Layer (SSL) und IP Security (IPSec) 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
3
http://www.gnupg.de
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 Payload
IP−Header 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? – IPSec 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
Next Header,
Length
SPI
Payload
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 ei7
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]
Glenn, R. und S. Kent: RFC 2410: The NULL Encryption Algorithm and Its Use With IPsec, November 1998. Status: PROPOSED STANDARD.
[HC98]
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: PROPOSED 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