11 Die IPSec-Sicherheitsarchitektur

Transkript

1 Die IPSec-Sicherheitsarchitektur Die IPSec-Sicherheitsarchitektur umfasst eine Reihe von Protokollen und eine Rahmenarchitektur zur Sicherung der Protokolldateneinheiten des Internet Protocol (IP). In diesem Kapitel werden nach einer kurzen Auffrischung des essenziellen Grundwissens über das Internet Protocol zunächst die wesentlichen Komponenten der IPSec-Architektur in einem Überblick vorgestellt und dann in weiteren Abschnitten detailliert erläutert Kurze Einführung in die Internet-Protokollfamilie Das Internet Protocol erfüllt als Protokoll der Netzwerkschicht die Aufgabe, Kommunikation zwischen Systemen zu ermöglichen, die nicht direkt über ein gemeinsames Medium miteinander verbunden sind. Hierfür bietet IP einen verbindungslosen Datagrammdienst an, der keine Garantien für die Auslieferung der Pakete gibt und daher als unzuverlässig (im Englischen: unreliable ) charakterisiert wird. Diese Charakterisierung von IP als unzuverlässig soll jedoch nicht zu der Vermutung Anlass geben, dass in der Praxis bei einem normal ausgelasteten Internetz häufig IP-Pakete nicht korrekt zugestellt werden, es werden lediglich im Protokoll keine expliziten Mechanismen vorgesehen, eine korrekte Auslieferung oder gar weiter gehende Zusicherungen bezüglich der Dienstqualität (z.b. Ende-zu-Ende-Verzögerung oder Schwankung der Verzögerung) zu garantieren. Der Dienst von IP wird daher auch als Best Effort ( bestmöglich ) bezeichnet. Abbildung 11.1 zeigt die Einbettung von IP in die TCP/IP- Protokollfamilie. Diese gliedert die verteilte Informationsverarbeitung in Systemen, die über ein Internetz (d.h. ein Netz von Netzen ) verbunden sind, in vier Protokollschichten: Unzuverlässiger Datagrammdienst Best Effort -Dienst TCP/IP- Protokollfamilie eine Reihe von Zugangsprotokollen, die Funktionen bis ein- Zugangsprotokolle schließlich der zweiten OSI-Schicht erfüllen und in der Pra-

2 Die IPSec-Sicherheitsarchitektur Abbildung 11.1 Verteilte Informationsverarbeitung auf Basis der TCP/IP- Protokollfamilie TCP IP UDP System B Internet TCP IP UDP System C TCP IP UDP Anwendungsprotokoll Zugangsprotokoll Anwendungsprotokoll Zugangsprotokoll Anwendungsprotokoll Zugangsprotokoll System A Internet Protocol (IP) Transmission Control Protocol (TCP) User Datagram Protocol (UDP) Anwendungsprotokolle xis häufig durch ein LAN-Protokoll wie Ethernet, Token- Ring, Wireless LAN oder im Fall von seriellen Wählverbindungen durch PPP realisiert werden, das Internet Protocol (IP), das einen unzuverlässigen, verbindungslosen Datagrammdienst erbringt, das Transmission Control Protocol (TCP), das einen zuverlässigen, verbindungsorientierten Transportdienst auf der Grundlage von IP erbringt, das User Datagram Protocol (UDP), das einen unzuverlässigen und verbindungslosen Transportdienst erbringt und somit im Wesentlichen lediglich eine Anwendungsschnittstelle zu IP mit Adressierung von Anwendungsprozessen darstellt, eine Reihe von Anwendungsprotokollen, wie beispielsweise das Simple Mail Transfer Protocol (SMTP) für die Zustellung elektronischer Post und das Hypertext Transfer Protocol (HTTP) zur Übermittlung von Hypertextstrukturen, um nur die beiden wichtigsten aktuell verwendeten Anwendungsprotokolle aufzuzählen. Abbildung 11.2 zeigt die Struktur eines IP-Pakets. Die in dem Protokollkopf enthaltenen Felder tragen die folgende Bedeutung: Version Version (Ver.): Dieses vier Bit umfassende Feld gibt die Protokollversion an. Zurzeit wird immer noch die Version 4 des Protokolls von den meisten Systemen eingesetzt, obwohl bereits seit einiger Zeit die Nachfolgerversion 6 spezifiziert ist (die Versionsnummer 5 wurde lediglich für eine nicht fertig spezifizierte Zwischenversion verwendet).

3 11.1 Kurze Einführung in die Internet-Protokollfamilie 217 Ver. IHL TOS Length IP Identification Flags Fragment Offset TTL Protocol IP Checksum Source Address Destination Address IP Options (sofern vorhanden) Abbildung 11.2 Format eines IP-Pakets TCP / UDP /... Payload Internet Length (IHL): Dieses vier Bit umfassende Internet Feld gibt die Länge des IP- in 32 bit breiten Worten Length an. Type of Service (TOS): Dieses acht bit breite Feld war ur- Type of Service sprünglich dafür vorgesehen, bestimmte Dienstqualitätsanforderungen für das Paket in Form einer Priorisierung auszudrücken. Seine Verwendung wird zurzeit innerhalb der IETF diskutiert. Length: In diesem 16 bit breiten Feld wird die Gesamtlänge Length des Pakets inklusive Paketkopf und Nutzdaten in Oktetten angeben. Wie alle anderen Protokollfelder in der TCP/IP- Protokollfamilie ist auch dieses Feld in der Big Endian - Repräsentation kodiert. IP Identification: Das Feld dient der eindeutigen Identifi- IP Identification kation eines IP-Pakets und ist von zentraler Bedeutung für die Segmentierung und Reassemblierung fragmentierter IP- Pakete. Flags: Das Feld enthält drei Bits zur Anzeige, ob ein IP-Paket Flags fragmentiert werden darf oder ob es sich bei einem IP-Paket bereits um ein Fragment eines größeren Pakets handelt, und ein Bit, das für zukünftige Anwendungen reserviert ist. Fragment Offset: Dieses 13 bit breite Feld enthält die Position Fragment Offset eines Fragments innerhalb eines fragmentierten IP-Pakets. Time to Live (TTL): In jedem IP-verarbeitenden Netzknoten Time to Live wird dieses 8 bit breite Feld um eins dekrementiert. Wenn das TTL-Feld den Wert 0 enthält, wird das Paket an dem nächsten Netzknoten verworfen, sofern es sich bei diesem Knoten nicht um das Ziel des Pakets handelt. Auf diese Weise werden endlos kreisende IP-Pakete verhindert.

4 Die IPSec-Sicherheitsarchitektur Protocol Protocol: Dieses acht Bit umfassende Feld zeigt das (Transport-) Protokoll der enthaltenen Nutzlast an und dient somit in den Endsystemen dazu, die für die Nutzdaten richtige Protokollinstanz (TCP, UDP etc.) zu identifizieren. IP Checksum Source Address Destination Address IP Checksum: Die in diesem Feld enthaltene 16 bit lange Prüfsumme dient der Erkennung von Fehlern in dem Protokollkopf. Da es sich hierbei nicht um eine kryptografische Prüfsumme handelt, kann sie einfach vorsätzlich gefälscht werden. Source Address: Dieses Feld enthält die 32 bit lange Quelladresse des sendenden Systems. Destination Address: Dieses ebenfalls 32 bit lange Feld enthält die Zieladresse des intendierten Empfängers des IP-Pakets. IP Options Sicherheitsmängel des IP-Protokolls Nachrichtenauthentisierung und Datenintegrität IP Options: Ein IP-Paketkopf kann optionale Informationen variabler Länge enthalten. Da Optionen nicht wesentlich für die IPSec-Sicherheitsarchitektur sind, werden sie an dieser Stelle nicht weiter erläutert. Das Internet Protocol weist eine Reihe von Sicherheitsmängeln auf, da bei seiner Entwicklung Sicherheitsaspekte nicht in die Anforderungen mit einbezogen wurden. So kann eine Instanz, die ein IP-Paket empfängt, keinerlei Schlüsse im Hinblick auf die folgenden Sicherheitseigenschaften ziehen: Nachrichtenauthentisierung und Datenintegrität: Wurde das Paket tatsächlich von der Instanz gesendet, die im Protokollkopf als Sender angegeben ist, und enthält das Paket noch exakt den Inhalt, den der ursprüngliche Sender abgesendet hat, oder wurde der Paketinhalt auf dem Weg bis zur empfangenden Instanz modifiziert? Ist die in dem Paketkopf angegebene Zieladresse tatsächlich die Adresse, an die der Sender das Paket ursprünglich senden wollte? Wiedereinspielung von Paketen Vertraulichkeit Schutz vor Wiedereinspielung von Paketen: Handelt es sich bei diesem Paket um ein aktuelles Paket des Senders oder um eine vorsätzliche Wiedereinspielung des Pakets durch einen böswilligen Angreifer? Vertraulichkeit: Wurde das Paket während seines Weges vom Sender zum Empfänger durch Dritte unberechtigt ausgespäht?

5 11.2 Überblick über die IPSec-Architektur Überblick über die IPSec-Architektur Die IPSec-Sicherheitsarchitektur hat zum Ziel, die am Ende des vorigen Abschnitts aufgeworfenen Sicherheitsmängel zu beheben. Somit strebt sie die folgenden Sicherheitsziele an: Sicherheitsziele von IPSec Nachrichtenauthentisierung und Datenintegrität: Es soll nicht möglich sein, ein IP-Paket mit einer gefälschten Quelladresse zu senden oder die Zieladresse eines IP-Pakets nachträglich zu modifizieren, ohne dass der Empfänger des Pakets das bemerkt. Ebenso soll es nicht möglich sein, den Inhalt eines Pakets zu modifizieren, ohne dass der Empfänger das feststellen kann. Schutz vor Wiedereinspielung von Paketen: Es soll nicht möglich sein, ein Paket zu einem späteren Zeitpunkt wiedereinzuspielen, ohne dass der Empfänger das feststellen kann. Vertraulichkeit: Es soll nicht möglich sein, den Inhalt von übertragenen IP-Paketen auszulesen. Weiterhin soll ein begrenzter Schutz vor Verkehrsflussanalysen mit IPSec realisiert werden können. Ein weiteres zentrales Ziel der IPSec-Architektur besteht darin, dass der Sender, der Empfänger und alle Zwischenknoten die Möglichkeit haben, anhand einer lokalen Sicherheitsstrategie (Security Policy) zu entscheiden, welche Sicherheitsanforderungen sie an bestimmte IP-Verkehrsströme stellen wollen. Die sendenden Instanzen (End- und Zwischensysteme) sichern die IP-Pakete gemäß der lokalen Sicherheitsstrategie und empfangende Instanzen verwerfen Pakete, die nicht über einen ausreichenden Schutz verfügen, da sie diesen Paketen kein ausreichendes Vertrauen entgegenbringen können. Abbildung 11.3 zeigt die wesentlichen Komponenten der IPSec-Architektur im Überblick. Die zentralen Konzepte der Architektur werden in RFC 2401 [KA98c] definiert. Dazu gehören das Konzept der Sicherheitsassoziation (Security Association, SA), die konzeptionelle Datenbank der Sicherheitsassoziationen (SADB), die Sicherheitsstrategie (Security Policy) sowie die konzeptionelle Datenbank der Sicherheitsstrategien (SPD). Weiterhin gibt RFC 2401 einen Überblick über die beiden grundlegenden Sicherheitsprotokolle der Architektur, den Authentication (AH) und die Encapsulating Security Payload (ESP), die beide in eigenen RFCs spezifiziert sind. Beide Protokolle können in Sicherheitsstrategie Zentrale Konzepte und Komponenten

6 Die IPSec-Sicherheitsarchitektur IPSec-Architecture RFC 2401 Encapsulating Security Payload RFC 2406 Authentication RFC 2402 Key Management DES-CBC RFC 2405 HMAC-MD5 RFC 2403 Photuris RFC 2522 SKIP (veralteter Internet Draft) CBC Mode Cipher Algorithms RFC 2451 HMAC-SHA-1 RFC 2404 ISAKMP RFCs 2407, 2408 HMAC- RIPEMD-160 RFC 2857 Internet Key Exchange RFC 2409 Oakley Key Mgmt. Protocol RFC 2412 verwendet besteht aus Abbildung 11.3 Überblick über die IPSec-Standards einem von zwei möglichen Operationsmodi, dem Transport Mode oder dem Tunnel Mode, betrieben werden. Schließlich spezifizieren weitere RFCs die Details der Verwendung spezifischer kryptografischer Operationen mit AH und ESP: Für die Verschlüsselung sind die Verwendung von DES sowie weitere Blockchiffren im Cipher Block Chaining -Modus vorgesehen. Die Nachrichtenauthenisierung und Integritätssicherung von IP-Paketen erfolgt mit einer HMAC-Konstruktion, wobei als kryptografische Hashfunktionen bisher MD5, SHA-1 und RIPEMD-160 vorgesehen sind. Sicherheitsassoziation (SA) Die Aushandlung der erforderlichen Schlüssel für die oben angegebenen kryptografischen Operationen wird zusammen mit der Instanzenauthentisierung durch die beiden sich einander ergänzenden Protokolle Internet Security Association and Key Management Protocol (ISAKMP) und Internet Key Exchange (IKE) realisiert. Eine Sicherheitsassoziation (Security Association, SA) kann hierbei als eine Art Simplex-Verbindung aufgefasst werden, die bestimmte Sicherheitsdienste für den in ihr transportierten Verkehr realisiert. Der Begriff Verbindung ist hierbei deshalb mit

7 11.2 Überblick über die IPSec-Architektur 221 Anführungszeichen zu gebrauchen, da das Internet Protocol ja einen verbindungslosen und damit für alle beteiligten Instanzen auch zustandslosen Dienst realisiert. Für die Realisierung von Sicherheitsdiensten wird jedoch ein bestimmtes Zustandswissen z.b. in Hinblick auf zu verwendende Sicherheitsmechanismen und Schlüssel bei den jeweiligen Partnerinstanzen benötigt. Dieser Zustand wird durch die Einrichtung, Verwendung und Auflösung von Sicherheitsassoziationen zwischen den jeweiligen Partnerinstanzen verwaltet. Da eine SA grundsätzlich nur für eine Kommunikationsrichtung verwendet wird, werden für bidirektionale Kommunikationsbeziehungen stets zwei Sicherheitsassoziationen benötigt. Die für eine SA ausgehandelten Sicherheitsdienste werden durch die Verwendung exakt eines der beiden Sicherheitsprotokolle Authentication (AH) oder Encapsulating Security Payload (ESP) erbracht. Die pro System eindeutige Identifikation einer SA erfolgt durch ein Tripel, das aus einem so genannten Security Parameter Index (SPI), einer IP-Zieladresse und dem Identifikator eines der beiden Sicherheitsprotokolle (AH oder ESP) besteht. Eine Sicherheitsassoziation kann grundsätzlich zwischen den folgenden Instanzen eingerichtet werden: Identifikation von SAs Partnerinstanzen von SAs Endsystem Endsystem Endsystem Zwischensystem Zwischensystem Zwischensystem Für die Verwaltung und Festlegung von Sicherheitsassoziationen sind in jedem System zwei konzeptionelle Datenbanken vorzuhalten. Die Datenbank der Sicherheitsassoziationen (Security Association Database, SADB) enthält die jeweils zu einem Zeitpunkt in dem System aktiven Sicherheitsassoziationen, und die Datenbank der Sicherheitsstrategien (Security Policy Database, SPD) definiert, welche Sicherheitsdienste auf welche IP-Pakete angewendet werden müssen und in welcher Weise diese Anwendung zu erfolgen hat. Die SPD gibt somit vor, für welche Datenströme Sicherheitsassoziationen mit welchen Partnerinstanzen eingerichtet und welche Parameter für diese Assoziationen ausgehandelt werden müssen. Diese Datenbanken werden deshalb als konzeptionelle Datenbanken bezeichnet, da für ihre Realisierung keine echte Datenbanktechnologie (z.b. relationale Datenbank mit allgemeiner Abfragesprache SQL) verwendet werden Verwaltung und Festlegung von SAs

8 Die IPSec-Sicherheitsarchitektur Protokollvarianten (Protocol Modes) Transportmodus Tunnelmodus muss. Die Implementierung dieser Datenbanken ist in der IPSec- Sicherheitsarchitektur nicht festgelegt und in der Regel werden hierfür auch keine allgemeinen Datenbankkonzepte eingesetzt. Eine Sicherheitsassoziation wird grundsätzlich in genau einer der beiden folgenden Varianten betrieben: Der Transportmodus (Transport Mode) kann lediglich zwischen den Endpunkten einer Kommunikationsbeziehung eingesetzt werden, d.h. zwischen zwei Endsystemen oder falls ein Datenstrom direkt für ein Zwischensystem bestimmt ist (z.b. bei Netzwerkmanagementanwendungen) zwischen einem Endsystem und einem Zwischensystem. Der Tunnelmodus (Tunnel Mode) kann zwischen beliebigen Systemen eingesetzt werden. Der Unterschied zwischen den beiden Protokollvarianten besteht darin, dass der Transportmodus lediglich einen sicherheitsspezifischen Protokollkopf (und evtl. einen Nachspann) hinzufügt, während der Tunnelmodus die zu schützenden IP-Pakete vollständig kapselt (vergleiche hierzu auch Abbildung 11.4). Die Kapselung von IP-Paketen ermöglicht es Zwischensystemen, bestimmte Datenströme stellvertretend für andere Instanzen zu schützen. Auf diese Weise kann beispielsweise ein einheitlicher Schutz für ganze Subnetze durch ein Zwischensystem realisiert werden. Abbildung 11.4 Paketformate des Transport- und des Tunnelmodus IP IPSec a.) Transport Mode Protected Data IP IPSec IP Protected Data b.) Tunnel Mode Authentication (AH) Das Sicherheitsprotokoll Authentication (AH) [KA98a] realisiert für die zu schützenden IP-Pakete den Sicherheitsdienst Nachrichtenauthentisierung mit Schutz vor Wiedereinspielung von Paketen. Es wird wie sein Name bereits andeutet durch einen Protokollkopf realisiert, der zwischen dem IP-Protokollkopf und den Nutzdaten des IP-Pakets eingefügt wird (vergleiche hierzu Abbildung 11.5).

9 11.2 Überblick über die IPSec-Architektur 223 IP AH authentisiert Protected Data Abbildung 11.5 Struktur eines IP-Pakets mit Authentication (AH) Im Vergleich hierzu realisiert das Sicherheitsprotokoll Encapsulating Security Payload (ESP) [KA98b] eine optionale Nachrichtenauthentisierung mit Schutz vor Wiedereinspielung von Paketen und ebenfalls optional die Vertraulichkeit für die übertragenen Nutzdaten, wobei mindestens einer der beiden optionalen Sicherheitsdienste für eine SA ausgewählt sein muss. Die Realisierung des Protokolls erfolgt mit einem zusätzlichen Protokollkopf und einem Nachspann, zwischen denen die Nutzdaten des IP-Pakets gekapselt werden (vergleiche hierzu Abbildung 11.6). Encapsulating Security Payload (ESP) IP ESP Protected Data authentisiert verschlüsselt ESP Trailer Abbildung 11.6 Struktur eines IP-Pakets mit Encapsulating Security Payload (ESP) Die Aushandlung und Einrichtung von Sicherheitsassoziationen erfolgt auf der Grundlage der beiden Protokolle Internet Security Association Key Management Protocol (ISAKMP) und Internet Key Exchange (IKE). Das Protokoll ISAKMP [MSST98] definiert hierfür ein generisches Rahmenwerk für die Instanzenauthentisierung, den Schlüsselaustausch und die Aushandlung von Parametern für Sicherheitsassoziationen. Es spezifiziert kein konkretes Authentisierungsprotokoll, sondern legt vielmehr die Sprache für die Definition solcher Protokolle fest, indem es grundlegende Dinge wie Paketformate, Zeitgeber für Übertragungswiederholungen, Anforderungen an die Konstruktion von Nachrichten etc. vorgibt. Im Prinzip ist ISAKMP als generelles Protokoll für die Authentisierung und Aushandlung von Sicherheitsparametern unabhängig von IPSec definiert. Der Einsatz von ISAKMP für IPSec wird getrennt von der eigentlichen Protokolldefinition in RFC 2407 [Pip98] näher ausgeführt. Das in RFC 2409 [HC98] spezifizierte Protokoll Internet Key Exchange (IKE) definiert ein konkretes Authentisierungs- und Schlüsselaustauschprotokoll, das konform zu ISAKMP ist und Einrichtung von Sicherheitsassoziationen Internet Security Association Key Management Protocol (ISAKMP) Internet Key Exchange (IKE)

10 Die IPSec-Sicherheitsarchitektur Schutz vor Wiedereinspielung Sliding Window - Mechanismus für unterschiedliche Zwecke eingesetzt werden kann, wobei sein Haupteinsatzgebiet in der Praxis die Aushandlung von Sicherheitsassoziationen für IPSec ist. Diese Aushandlung erfolgt hierbei in zwei Phasen: In der ersten Phase wird zunächst eine so genannte IKE SA eingerichtet, die festlegt, auf welche Weise weitere Sicherheitsassoziationen für den Schutz konkreter Datenströme in der zweiten Phase zwischen den beiden Partnerinstanzen ausgehandelt werden sollen. Der Schutz vor Wiedereinspielung von IP-Paketen wird in den beiden Sicherheitsprotokollen AH und ESP auf der Grundlage einer Sequenznummer realisiert. Diese Sequenznummer wird bei der Einrichtung einer SA mit dem Wert 0 initialisiert und mit jedem gesendeten Paket um 1 inkrementiert. Bevor ein Überlauf dieser 32 bit langen Sequenznummer erfolgt, muss der für die SA vereinbarte Sitzungsschlüssel durch einen neuen Schlüssel ersetzt werden. Da diese Sequenznummer mit in die Berechnung des Nachrichtenauthentisierungswertes einbezogen wird, kann sie von einem Angreifer nicht unbemerkt modifiziert werden. Der Empfänger eines mit IPSec geschützten Pakets überprüft stets, ob die in dem Paket enthaltene Sequenznummer in einem Bereich zu akzeptierender Nummern liegt. Dieser Bereich wird in Anlehnung an die englische Bezeichnung Sliding Window auch als gleitendes Fenster zu akzeptierender Nummern bezeichnet. Der Grund für die Verwendung eines ganzen Bereichs liegt darin, dass es im Internet auch bei ungestörtem Betrieb protokollbedingt zu Reihenfolgevertauschungen von IP-Paketen kommen kann, so dass unter Umständen später abgesendete Pakete vor früher gesendeten Paketen bei dem Empfänger eintreffen können. Würde der Empfänger nun auf einer strengen Reihenfolge der Sequenznummern bestehen, so müsste er auch unbeabsichtigt in ihrer Reihenfolge vertauschte IP-Pakete verwerfen, wodurch der Datendurchsatz im Internet unnötig reduziert würde. Aus diesem Grund akzeptiert der Empfänger IP-Pakete grundsätzlich dann, wenn sie nicht zu alt sind, das heißt, wenn nicht bereits neuere IP-Pakete empfangen wurden, deren Sequenznummer erheblich größer ist. Dieser Sachverhalt wird in den Abbildungen 11.7 und 11.8 illustriert. Abbildung 11.7 zeigt ein Beispiel mit einem Empfangsfenster der Größe 16. Die noch nicht empfangenen Pakete sind darin durch graue Kästchen dargestellt, der Vektor der bereits empfangenen Pakete zeigt an diesen Stellen entsprechend eine 0 und an den anderen Stellen eine 1. Unter der Annahme, dass das aktu-

11 11.2 Überblick über die IPSec-Architektur 225 Gleitendes Fenster bereits empfangener Pakete Fenstergröße muss in Praxis mindestens 32 betragen Sequenznummer N Sequenznummer N + 7 Sequenznummer N + 16 Paket N+17 wird empfangen Das Paket mit Sequenznummer N kann noch angenommen werden ellste empfangene Paket die Sequenznummer N + 15 trägt, kann das Paket mit der Sequenznummer N noch angenommen werden. Trifft jedoch vor dem Empfang dieses Pakets bereits das Paket mit der Sequenznummer N + 17 ein, so wird das Fenster um zwei Stellen nach vorne gerückt (siehe Abbildung 11.8), so dass das Paket mit der Sequenznummer N nun links von dem Empfangsfenster liegt und damit bei nachträglichem Empfang als zu alt verworfen wird. Abbildung 11.7 Beispiel eines gleitenden Fensters vor der Aktualisierung Gleitendes Fenster bereits empfangener Pakete Abbildung 11.8 Beispiel eines gleitenden Fensters nach Fortschreiben des Fensters Sequenznummer N Sequenznummer N + 7 Sequenznummer N + 16 Das Paket mit Sequenznummer N kann nicht mehr angenommen werden In RFC 2401 wird als minimale Fenstergröße der Wert 32 vorgeschrieben und der Wert 64 als Standardvorgabe empfohlen. Bei Empfang eines IP-Pakets werden von dem empfangenden System insgesamt die folgenden Aktionen in Abhängigkeit der Sequenznummer getroffen: Liegt die Sequenznummer links von dem Empfangsfenster, wird das Paket verworfen. Aktionen des Empfängers Liegt die Sequenznummer innerhalb des Empfangsfensters, wird der Nachrichtenauthentisierungswert überprüft und

12 Die IPSec-Sicherheitsarchitektur das Paket angenommen, falls diese Überprüfung erfolgreich ist. Liegt die Sequenznummer rechts des Empfangsfensters, wird der Nachrichtenauthentisierungswert überprüft und im Erfolgsfall das Paket angenommen und das Fenster nach rechts verschoben. Implementierungsvarianten von IPSec Implementierung im Endsystem Wie bereits weiter oben erwähnt wurde, kann IPSec sowohl in Endsystemen als auch in Zwischensystemen implementiert werden. In beiden Fällen ergeben sich jeweils zwei Implementierungsvarianten, die im Folgenden kurz beschrieben werden sollen. Aus einer Implementierung im Endsystem ergeben sich grundsätzlich die Vorteile, dass auf diese Weise echte Ende-zu- Ende-Sicherheitsdienste realisiert werden können, dass spezifische Sicherheitsdienste individuell für jeden Datenstrom möglich sind und dass sowohl der Transport- als auch der Tunnelmodus eingesetzt werden können. Abbildung 11.9 Integrationsalternativen für IPSec in Endsysteme Betriebssystemintegration Application Transport Network + IPSec Data Link Integration als Zwischenschicht Application Transport Network IPSec Data Link Weiterhin existieren die beiden in Abbildung 11.9 illustrierten Implementierungsalternativen: Integration von IPSec in die Protokollverarbeitungsfunktionen des Betriebssystems und Integration als Zwischenschicht zwischen der IP-Schicht und der Schicht des Zugangsprotokolls. Die letztgenannte Variante wird hierbei hauptsächlich angewendet, wenn das Betriebssystem selbst nicht modifiziert werden kann (beispielsweise wenn es nicht im Quellcode vorliegt). Eine direkte Integration in das Betriebssystem ist jedoch klar vorzuziehen, da sie eine Duplizierung von Protokollfunktionalität vermeidet.

13 11.3 Einsatz des Transport- und des Tunnelmodus 227 Die Implementierung von IPSec in Zwischensystemen bietet den Vorteil, dass hiermit die zwischen zwei Subnetzen über das öffentliche Internet ausgetauschten IP-Pakete auf einheitliche Weise gesichert und somit Virtuelle Private Netze (VPN) gebildet werden können. Weiterhin muss in diesem Fall IPSec nicht in jedem Endsystem implementiert und konfiguriert werden, und es kann der zwischen entfernten Benutzern und einem Subnetz ausgetauschte IP-Verkehr auf einheitliche Weise gesichert und autorisiert werden. Implementierung in Zwischensystemen Vermittlungssystemintegration RB RA Internet RC Vorschaltung externer Einheiten Link RB RA B RA Internet RA C RC Abbildung Integrationsalternativen für IPSec in Zwischensysteme In Bezug auf die Realisierung von IPSec für Zwischensysteme existieren die beiden in Abbildung gezeigten Alternativen: Integration direkt in das Vermittlungssystem und Vorschaltung externer Einheiten. Während bei der ersten Variante die IPSec- Funktionalität unmittelbar in die Protokollfunktionen des Vermittlungssystems integriert wird, werden bei der zweiten Alternative vor jeden zu schützenden Ein- bzw. Ausgang des Zwischensystems zusätzliche IPSec-Module geschaltet. Aus Effizienzgründen ist eine direkte Integration vorzuziehen, und so ist die zweite Alternative lediglich als Übergangslösung für nicht IPSec-fähige Vermittlungssysteme gedacht Einsatz des Transport- und des Tunnelmodus In diesem Abschnitt sollen die Unterschiede des Transport- und des Tunnelmodus näher erläutert sowie ihre spezifischen Einsatzsszenarien erklärt werden. Hierfür sind zunächst die beiden Begriffe Kommunikationsendpunkt und kryptografischer Endpunkt voneinander abzugrenzen.

14 Die IPSec-Sicherheitsarchitektur Definition 11.1 Die Kommunikationsendpunkte eines Datenstroms bezeichnen das Quell- und das Zielsystem der ausgetauschten IP-Pakete. Demgegenüber werden die Systeme, welche im Rahmen einer Sicherheitsassoziation die AH- bzw. ESP-Protokollköpfe der ausgetauschten IP-Pakete generieren und verarbeiten als kryptografische Endpunkte bezeichnet. Kommunikationsendpunkte und kryptografische Endpunkte Einsatzgebiete von Transport- und Tunnelmodus Mit diesen beiden Begriffen können die Einsatzgebiete des Transport- und des Tunnelmodus einfach unterschieden werden: Der Transportmodus wird verwendet, wenn die kryptografischen Endpunkte mit den Kommunikationsendpunkten übereinstimmen (vergleiche hierzu Abbildung 11.11). Der Tunnelmodus wird verwendet, wenn mindestens ein kryptografischer Endpunkt kein Kommunikationsendpunkt ist (siehe auch Abbildungen und 11.13). Abbildung Ende-zu-Ende- Sicherung mit dem Transportmodus A SA A,B B Internet IP-Paketfluss Intranet-Szenario In den meisten Fällen liegen die Kommunikationsendpunkte in Endsystemen (Personal Computer, Arbeitsstationen, Server), jedoch ist das nicht notwendigerweise so: Wird beispielsweise ein Zwischensystem per Simple Network Management Protocol (SNMP) von einer Managementstation aus verwaltet, so sind die in diesem Zusammenhang ausgetauschten IP-Pakete an das Zwischensystem adressiert bzw. werden von diesem gesendet. Abbildung zeigt den Einsatz des Tunnelmodus in Zwischensystemen sowie die Struktur der zwischen den beiden Endsystemen A und B ausgetauschten Pakete im Internet. Bei der Vermittlung der von A an B gesendeten Pakete entscheidet das Zwischensystem RA anhand seiner lokalen Sicherheitsstrategie, dass die

15 11.3 Einsatz des Transport- und des Tunnelmodus 229 A RA SA RA,RB RB B Abbildung Einsatz des Tunnelmodus in Zwischensystemen Internet IP-Paketfluss IP Src = RA Dst = RB IPSec Paketstruktur IP Src = A Dst = B Protected Data Pakete auf der Grundlage einer mit RB ausgehandelten Sicherheitsassoziation zu sichern sind. Daraufhin erstellt es einen entsprechenden IPSec-Protokollkopf (AH oder ESP), der vor das gesamte IP-Paket inklusive des ursprünglichen IP-Protokollkopfes gesetzt wird. Schließlich erstellt es einen neuen IP-Protokollkopf, der an RB adressiert ist und dem IPSec-Protokollkopf vorangestellt wird. Das ursprüngliche IP-Paket wird somit in einem Tunnel zwischen RA und RB durch das Internet transportiert, wodurch auch die Bezeichnung Tunnelmodus begründet ist. In der Praxis findet sich eine derartige Konfiguration vor allem bei der Vernetzung zweier privater Subnetze an verschiedenen Standorten über das öffentliche Internet ( Intranet-Szenario ). A RA SA A,RB Internet RB B Abbildung Einsatz des Tunnelmodus zwischen einem Endund einem Zwischensystem IP-Paketfluss Paketstruktur IP IPSec IP Protected Data Src = A Dst = RB Src = A Dst = B

16 Die IPSec-Sicherheitsarchitektur Road Warrior - Szenario Verschachtelung von Sicherheitsassoziationen Ein anderes Einsatzszenario für den Tunnelmodus zeigt Abbildung 11.13, in der wiederum die beiden Endsysteme A und B miteinander kommunizieren, dieses Mal jedoch die Sicherung der Pakete zwischen A und RB erfolgt. Da der kryptografische Endpunkt RB nicht gleich dem Kommunikationsendpunkt B ist, werden die Pakete zwischen A und RB vollständig gekapselt. Ein typisches Anwendungsbeispiel für diese Konfiguration ist das so genannte Road Warrior Szenario, in dem Mitarbeiter einer Firma von entfernten Standorten (z.b. Hotelzimmer) aus auf Dienste des privaten Subnetzes der Firma zugreifen müssen. Sicherheitsassoziationen können auch verschachtelt werden, wie in Abbildung illustriert wird. Ein Anwendungsbeispiel hierfür ist, dass die zwischen A und RB ausgetauschten Daten grundsätzlich authentisiert werden und dass darüber hinaus alle zwischen RA und RB ausgetauschten Daten verschlüsselt werden und somit Vertraulichkeit auf Subnetzebene realisiert wird. Wie der Abbildung auch zu entnehmen ist, wird für jede Sicherheitsassoziation ein eigener IPSec- und ein eigener IP-Protokollkopf den Paketen hinzugefügt. Abbildung Verschachtelung von Sicherheitsassoziationen A RA Internet SA A,RB RB B SA RA,RB IP Src = RA Dst = RB IPSec IP Src = A Dst = RB IP-Paketfluss Paketstruktur IPSec IP Src = A Dst = B Protected Data Bei der Verschachtelung von Sicherheitsassoziationen ist jedoch darauf zu achten, dass hierdurch keine überlappenden Tunnelsegmente geschaffen werden dürfen ( korrekte Klammerung ). Abbildung zeigt ein Beispiel zweier korrekt verschachtelter Assoziationen. Demgegenüber sind die in Abbildung gezeigten Sicherheitsassoziationen nicht korrekt verschachtelt. So werden die Pakete zwischen RB und RD in einem Tunnel transportiert, so dass RC den von RA für ihn hinzugefügten IPSec-Protokollkopf nicht

17 11.4 IPSec-Protokollverarbeitung 231 A RA RB Tunnel 2 RC RD D Abbildung Korrekte Verschachtelung zweier Sicherheitsassoziationen Tunnel 1 IP Src = RB Dst = RC IPSec IP Src = RA Dst = RD Paketstruktur IPSec IP Src = A Dst = D Protected Data analysieren und abstreifen kann. Weiterhin befindet sich das IP- Paket nach Abstreifen des äußeren Protokollkopfes im Zwischensystem RD an einer topologisch falschen Stelle im Netz, so dass es in Richtung RC zurückreisen muss und je nach Wert seines TTL-Feldes auf dem Weg dorthin verworfen wird. A RA RB Tunnel 1 RC Tunnel 2 RD D Abbildung Beispiel zweier falsch verschachtelter Sicherheitsassoziationen IP Src = RB Dst = RD IPSec IP Src = RA Dst = RC Paketstruktur IPSec IP Src = A Dst = D Protected Data 11.4 IPSec-Protokollverarbeitung Wie in den vergangenen Abschnitten bereits deutlich geworden ist, erlaubt die IPSec-Architektur, die Sicherung von IP-Paketen sowohl in Endsystemen als auch in Zwischensystemen vorzunehmen. Im Folgenden soll auf die hierfür in den Systemen bei der IP- Protokollverarbeitung erforderlichen zusätzlichen Verarbeitungs-

18 Die IPSec-Sicherheitsarchitektur IPSec-Verarbeitung ausgehender Pakete schritte eingangen werden. Hierbei zeigt sich, dass in End- und in Zwischensystemen im Wesentlichen die gleichen Funktionen zu erbringen sind, so dass bei der Darstellung lediglich zwischen ausgehenden und eingehenden Paketen unterschieden werden muss. Betrachten wir hierfür zunächst ein System, das ein bestimmtes IP-Paket an ein anderes System senden muss. Für die korrekte IPSec-Bearbeitung sind die folgenden Schritte erforderlich: 1. Bestimmen, ob das IP-Paket gesichert werden muss: Diese Entscheidung wird auf der Grundlage der lokalen Sicherheitsstrategie getroffen, die in der Security Policy Database (SPD) abgespeichert ist. Je nach der in dem entsprechenden SPD-Eintrag vorgeschriebenen Aktion wird das Paket nun entweder verworfen, ohne weitere Sicherung gesendet oder vor dem Senden noch gesichert. 2. Bestimmen der für das IP-Paket zu verwendenden Sicherheitsassoziation: Falls noch keine Sicherheitsassoziation mit der entsprechenden Partnerinstanz existiert, muss bei der Schlüsselverwaltungsinstanz wegen einer Authentisierung und Parameteraushandlung angefragt werden. 3. Auslesen der SA-Parameter: Die Parameter der gegebenenfalls frisch erzeugten SA werden aus der SADB ausgelesen. 4. Vornehmen der in der SA spezifizierten Sicherheitsmaßnahmen: Dieser Schritt resultiert in der Erstellung eines AH- bzw. ESP-Protokollkopfes sowie eines neuen IP- Protokollkopfes bei Verwendung des Tunnelmodus. Je nachdem, welche Sicherheitsdienste für die SA ausgehandelt wurden, werden die Nutzdaten in diesem Zusammenhang verschlüsselt und / oder mit einem Nachrichtenauthentisierungswert geschützt. Alle hierfür erforderlichen Parameter und Schlüssel sind in dem entsprechenden Eintrag in der SADB gespeichert. 5. Starten der IPSec-Verarbeitung für das resultierende Paket: Nachdem das IP-Paket fertig gestellt wurde, ist mit der für alle IP-Pakete üblichen Protokollverarbeitung fortzufahren (siehe Schritt 1). Der Grund hierfür liegt darin, dass bei verschachtelten Sicherheitsassoziationen gegebenfalls mehrere IPSec-Protokollköpfe in dem gleichen System hinzugefügt werden müssen (betrachte hierzu die Richtung von B nach A im Zwischensystem RB in Abbildung 11.14).

19 11.4 IPSec-Protokollverarbeitung 233 Für eingehende IP-Pakete sind in einem System die folgenden Verarbeitungsschritte durchzuführen: IPSec-Verarbeitung eingehender Pakete 1. Überprüfen, ob das Paket einen IPSec-Protokollkopf enthält, den dieses System bearbeiten muss: Bei dieser Prüfung wird in jedem Schritt nur der äußerste IPSec-Kopf betrachtet, da IPSec-Köpfe stets von außen nach innen abgestreift werden müssen. 2. Verarbeiten des äußeren IPSec-Kopfes: Sofern der äußere IPSec-Kopf tatsächlich für dieses System bestimmt ist, wird im nächsten Schritt die entsprechende SA aus der SADB abgefragt. Existiert diese SA nicht im lokalen System, muss das Paket verworfen werden. Konnte die korrekte SA gefunden werden, so wird das Paket entsprechend verarbeitet. Kommt es hierbei zu einem Fehler (z.b. falscher Nachrichtenauthentisierungswert), so wird das Paket ebenfalls verworfen. 3. Entscheide, ob das Paket korrekt gesichert ist: Hierfür wird in der SPD nach dem für das Paket zutreffenden Eintrag gesucht. Je nachdem, welche Aktion in der Sicherheitsstrategie vorgeschrieben ist, wird das Paket entweder verworfen oder entsprechend weiterverarbeitet. Hierbei ist erneut zu prüfen, ob ein weiterer IPSec-Kopf verarbeitet werden muss. Außerdem muss bis zur vollständigen Verarbeitung des Pakets (Weiterleitung an die entsprechende Transportinstanz bzw. Weitersenden des resultierenden IP-Pakets oder Verwerfen) Zustandsinformation gespeichert werden, so dass nach Abstreifen aller IPSec-Köpfe abschließend entschieden werden kann, ob das Paket, wie in der Sicherheitsstrategie gefordert, gesichert war. Wie sich in der bisherigen Diskussion gezeigt hat, ist die Selektion der Sicherheitsstrategie von zentraler Bedeutung für die IPSec- Protokollverarbeitung. Die Auswahl des für ein IP-Paket zutreffenden zutreffenden Security Policy Eintrags in der SPD erfolgt hierbei auf der Grundlage der folgenden Selektoren: IP-Quelladresse: Bei dieser kann es sich um die Adresse eines einzelnen Systems, ein Netzwerk-Präfix, einen Adressbereich oder einen nicht näher bestimmten Platzhalter ( Wildcard ) handeln. IP-Zieladresse: Diese wird auf die gleiche Weise wie die IP- Quelladresse spezifiziert. Bei gekapselten IP-Paketen (Tun-

20 Die IPSec-Sicherheitsarchitektur nelmodus) werden sowohl für die Quell- als auch für die Zieladresse stets die inneren IP-Paketköpfe ausgewertet. Name: Hierbei kann es sich um einen Domain Name System -Namen (DNS), einen X.500-Namen oder einen anderen Namen handeln, der in den IPSec-spezifischen Festlegungen für das zu verwendende Authentisierungsprotokoll (z.b. RFC 2407 für ISAKMP) spezifiziert ist. Namen werden nur für die Aushandlung von Sicherheitsassoziationen ausgewertet. Protokoll: Hiermit wird die Protokollidentifikation des Transportprotokolls für das betrachtete Paket bezeichnet. Im Fall von mit ESP verschlüsselten Nutzdaten müssen diese zunächst entschlüsselt werden, bevor entschieden werden kann, ob das Paket richtig gesichert ist. Die Entschlüsselung kann natürlich nur dann vorgenommen werden, wenn das System auch der kryptografische Endpunkt für diesen ESP-Kopf ist. Andernfalls wird ESP als Transportprotokoll angenommen und entschieden, ob das Paket weitergeleitet werden darf. Port des Anwendungsprotokolls: Sofern zugänglich, können auch die Dienstzugangspunkt-Identifikationen der Anwendungsprotokolle mit in die Auswahl der anzuwendenden Security Policy einbezogen werden. Inhalt von Security- Policy-Einträgen Aufgrund der genannten Merkmale wird der für ein Paket zutreffende Eintrag in der SPD selektiert. Ein solcher Eintrag enthält die folgenden Festlegungen: Vorgaben, wie eine so genannte Phase-I-SA (z.b. IKE SA) ausgehandelt werden soll beispielsweise mit dem Main- Modus oder dem Quick-Modus bzw. welche Protection-Suites verwendet werden sollen (siehe hierfür Abschnitte 11.7 und 11.8), und Vorgaben über die für IP-Pakete zu erbringenden Sicherheitsdienste. Diese umfassen weiterhin: Selektoren, die wiederum individuelle Datenströme identifizieren, die auszuführende Aktion für diese Datenströme (Verwerfen, direktes Weiterleiten oder Sichern) und

21 11.5 Das ESP-Protokoll 235 Sicherheitsattribute für zu sichernde Datenströme, wie beispielsweise das anzuwendende Sicherheitsprotokoll (AH oder ESP), der Protokollmodus (Transport- oder Tunnelmodus), Informationen über zu verwendende Sicherheitsalgorithmen und ihre Parameter sowie weitere Parameter, wie die Lebensdauer von Sicherheitsassoziationen und die Größe des Fensters für den Schutz vor Wiedereinspielung von Paketen. Sofern die einer Sicherheitsstrategie entsprechende SA bereits existiert, ist ihre Identifikation in der SPD vermerkt, so dass sie effizient aus der SADB abgefragt werden kann Das ESP-Protokoll Bei dem ESP-Protokoll handelt es sich um ein generisches Sicherheitsprotokoll, das für IP-Pakete die folgenden Sicherheitsdienste realisiert: Sicherheitsdienste von ESP Vertraulichkeit durch Verschlüsselung der Nutzlast (Tranportmodus) bzw. der vollständigen IP-Pakete (Tunnelmodus) sowie Nachrichtenauthentisierung und Schutz vor Wiedereinspielung von Paketen durch Hinzufügen eines Nachrichtenauthenisierungswertes und einer Sequenznummer. Beide Sicherheitsdienste sind optional und können miteinander kombiniert werden, jedoch muss für eine Sicherheitsassoziation mindestens eine der beiden Optionen ausgewählt sein. Die Spezifikation von ESP ist in mehrere Teile aufgeteilt: die Definition des eigentlichen Protokolls in RFC 2406 [KA98b] und die Verwendung spezifischer kryptografischer Algorithmen mit ESP, z.b. Verschlüsselung mit DES-CBC in RFC 2405 [MD98] bzw. mit weiteren Chiffrieralgorithmen im CBC in RFC 2451 [PA98] sowie die Nachrichtenauthentisierung mit HMAC-MD5 in RFC 2403 [MG98a] bzw. HMAC-SHA in RFC 2404 [MG98b]. Die eigentliche Protokolldefinition von ESP in RFC 2406 enthält die Spezifikation des Protokollkopfes und -anhangs, die grundlegenden Protokollverarbeitungsschritte sowie die Verfahrensweisen für den Transport- und Tunnelmodus. Abbildung zeigt das Paketformat des Encapsulating Security Payload. Der gezeigte ESP-Protokollkopf folgt direkt auf einen IP- Protokollkopf oder einen IPSec-Protokollkopf, wobei das Next Protokollfelder von ESP

22 Die IPSec-Sicherheitsarchitektur Abbildung Paketformat des Encapsulating Security Payload (ESP) verschlüsselt Security Parameter Index (SPI) Sequence Number Initialization Vector Protected Data authentisiert Pad Pad Length Next Authentication Data -Feld des voranstehenden Protokollkopfes mit dem Wert 50 anzeigt, das es sich hierbei um einen ESP-Protokollkopf handelt. Die Protokollfelder von ESP haben die folgende Bedeutung: Security Parameter Index (SPI) Sequenznummer Initialisierungsvektor (IV) Pad Pad Length Next Das Feld Security Parameter Index (SPI) kennzeichnet die SA, die für dieses Paket zu verwenden ist. Der in dieses Feld einzutragende Wert wird grundsätzlich bei der Aushandlung der SA von der empfangenden Seite festgelegt, da diese anhand des SPI-Wertes die SA eindeutig identifizieren können muss. Die Sequenznummer dient wie bereits erklärt dem Schutz vor Wiedereinspielung von IP-Paketen. Sofern der verwendete kryptografische Algorithmus einen Initialisierungsvektor (IV) benötigt, wird dieser in jedem IP- Paket im Klartext transportiert, damit jedes Paket isoliert von anderen verarbeitet werden kann. Das Pad-Feld sorgt zum einen dafür, dass die zu verschlüsselnde Nutzlast auf eine Länge aufgefüllt wird, die ein ganzzahliges Vielfaches der Blockgröße des verwendeten Algorithmus beträgt, und dass die beiden folgenden Felder in den höherwertigen 16 bit eines 32-bit-Wortes zu stehen kommen. Das Feld Pad Length gibt die Anzahl der hinzugefügten Oktette an. Das Feld Next zeigt den Protokolltyp der enthaltenen

23 11.5 Das ESP-Protokoll 237 Nutzlast an, z.b. TCP oder UDP. Das optionale Feld Authentication Data enthält sofern vor- Authentication Data handen einen Nachrichtenauthentisierungswert (MAC). Die Abbildungen und zeigen die Verarbeitungsschritte bei der Erstellung ausgehender ESP-Pakete. Anhand der durch die Sicherheitsstrategie festgelegten SA wird zunächst festgestellt, ob das Paket im Transport- oder im Tunnelmodus zu schützen ist. Nach der Erstellung der entsprechenden Protokollköpfe wird geprüft, ob das Paket zu verschlüsseln ist, und, wenn ja, die Verschlüsselung vorgenommen. Weiterhin wird geprüft, ob das Paket zu authentisieren ist, und, falls ja, ein Nachrichtenauthentisierungswert berechnet. Schließlich wird die Prüfsumme des äußeren IP-Protokollkopfes ermittelt. Protokollverarbeitung ausgehender Pakete Erstelle Tunnel- Mode- ESP: Ausgehende Bearbeitung Tunnel Modus? Transport Erstelle Transport- Mode- Abbildung Erstellung ausgehender ESP-Pakete (1/2) nein Chiffrieren? ja Chiffriere Nutzlast nein Signieren? ja Berechne MAC Berechne Prüfsumme des äußeren IP- In Abbildung ist die Erstellung der Protokollköpfe für den Transport und den Tunnelmodus illustriert. Im Tunnelmodus wird vor den vorhandenen IP-Protokollkopf zunächst ein ESP- Protokollkopf gesetzt, dessen Next -Feld auf IP gesetzt wird. Nach dem Ausfüllen der anderen ESP-spezifischen Felder Erstellung der Protokollköpfe

24 Die IPSec-Sicherheitsarchitektur Abbildung Erstellung ausgehender ESP-Pakete (2/2) Erstelle Tunnel- Mode- Setze ESP- vor IP- Erstelle Transport- Mode- Füge ESP- hinter IP- ein ESP.next = IP Belege andere ESP- -Felder ESP.next = IP.next IP.next = ESP Setze neuen IP- vor ESP- Belege andere ESP- -Felder NewIP.next = ESP NewIP.src = this.ip NewIP.dest = tunnelend.ip Protokollverarbeitung ankommender Pakete wird ein neuer IP-Protokollkopf vor den ESP-Kopf gesetzt, dessen Next -Feld auf ESP gesetzt wird und dessen Quell- und Zieladressfelder mit den Adressen der beiden Tunnelendpunkte gefüllt werden. Für die Erstellung des Protokollkopfes im Transportmodus wird zunächst ein ESP-Kopf zwischen dem IP-Kopf und der Nutzlast eingefügt. Das Next -Feld des ESP-Kopfes wird auf den Wert des entsprechenden Feldes im IP-Kopf gesetzt, bevor das Next -Feld dieses Kopfes auf den Wert ESP gesetzt wird. Anschließend werden die restlichen ESP-Felder ausgefüllt. Die beiden Abbildungen und zeigen die Schritte bei der Verarbeitung ankommender ESP-Pakete. Bei ankommenden Paketen muss zunächst geprüft werden, ob alle zu dem Paket gehörenden Fragmente bereits verfügbar sind, da andernfalls erst auf die restlichen Fragmente gewartet werden muss. Anschließend wird die für das Paket zu verwendende SA ausgelesen bzw. das Paket verworfen, wenn diese Assoziation lokal nicht existiert. Weiterhin wird überprüft, ob die enthaltene Sequenznummer in dem Fenster bzw. rechts von dem Fenster der zu akzeptierenden Sequenznummern liegt, und falls nicht wird das Paket verworfen. Nach der Überprüfung des Nachrichtenauthentisierungswertes wird das Paket je nach Resultat entweder verworfen oder es wird das Replay-Fenster gegebenenfalls nach rechts verschoben und die Bearbeitung des Pakets fortgesetzt.

25 11.5 Das ESP-Protokoll 239 ESP: Eingehende Bearbeitung (1) Alle Fragmente vorhanden? ja nein Warte auf Fragmente Abbildung Bearbeitung ankommender ESP-Pakete (1/2) Exisitiert SA für den SPI? ja Sequenznummer ok? ja Paket authentisch? ja Verschiebe Replay-Fenster & setze Bearbeitung fort nein nein nein Verwerfe Paket Verwerfe Paket Verwerfe Paket Die weitere Bearbeitung des Pakets ist in Abbildung dargestellt. Zunächst wird die Nutzlast des Pakets dechiffriert und dann geprüft, in welchem Modus das Paket gesichert wurde. Im Falle des Tunnelmodus müssen nur die beiden äußeren Protokollköpfe abgestreift werden und im Fall des Transportmodus muss zunächst der ursprüngliche Wert des Next -Feldes im IP-Protokollkopf wiederhergestellt werden, bevor der eingefügte ESP-Kopf entfernt und die Prüfsummer des IP-Protokollkopfes neu berechnet werden kann. Anschließend wird bei beiden Betriebsarten überprüft, ob das Paket mit den in der Security Policy vorgeschriebenen Sicherheitsmaßnahmen geschützt war, bevor es entweder verworfen oder an die entsprechende Protokollinstanz weitergeleitet wird. Bei einem auf diese Weise bearbeiteten und rekonstruierten IP-Paket kann es sich gegebenenfalls um ein fragmentiertes Paket handeln. Dieser Fall tritt beispielsweise auf, wenn ein Zwischensystem ESP im Tunnelmodus auf bereits fragmentierte Pakete anwendet. Bevor ein Zwischensystem für ein fragmentiertes Paket vollständig entscheiden kann, wie das Paket gemäß der lokalen Sicherheitsstrategie zu behandeln ist, müssen eigentlich alle Fragmente des Pakets im Zwischensystem vorliegen bzw. mindestens die Fragmente, welche die auszuwertenden Teile des Pakets ent- Behandlung fragmentierter Pakete

26 Die IPSec-Sicherheitsarchitektur Abbildung Bearbeitung ankommender ESP-Pakete (2/2) Tunnel ESP: Eingehende Bearbeitung (2) Dechiffriere Paket Modus? Transport Verwerfe äußeren IP- IP.next = ESP.next Verwerfe ESP- Verwerfe ESP- Berechne IP-Prüfsumme Entspricht das Paket der Policy der SA? ja Leite das Paket weiter nein Verwerfe Paket Alternativen für die Weiterleitung halten (z.b. bis einschließlich der Portfelder des Transportprotokollkopfes). So ist es beispielsweise möglich, dass innerhalb einer SA nur Pakete ausgetauscht werden dürfen, die an einen bestimmten Port gerichtet sind. Die hierfür auszuwertende Portinformation ist nur in dem ersten Fragment des IP-Pakets vorhanden. Weiterhin ist zu der oben erläuterten ESP-Verarbeitung zu bemerken, dass für die Weiterleitung des erhaltenen Pakets die folgenden Alternativen bestehen: Falls ein weiterer IPSec-Protokollkopf folgt, der an dieses System gerichtet ist, wird mit der IPSec-Bearbeitung fortgefahren. War das Paket im Tunnelmodus gesichert und ist das bearbeitende System nicht der Kommunikationsendpunkt des Pakets, so wird es gemäß der lokalen Routing-Information weitergeleitet. Ist das empfangene Paket für das System selbst bestimmt, wird es an die entsprechende Transportinstanz übergeben (z.b. TCP oder UDP). Falls ESP im Rahmen einer SA sowohl Vertraulichkeit als auch Nachrichtenauthentisierung leistet, so ist es möglich, für beide Sicherheitsdienste unterschiedliche Schlüssel zu verwenden, sofern dies bei der Aushandlung der SA vereinbart wird.

27 11.6 Das AH-Protokoll 241 Wie bereits eingangs erwähnt, ist die Spezifikation von ESP in die Definition des eigentlichen Protokolls und die Verwendung spezifischer kryptografischer Algorithmen mit ESP geteilt. Konkret wurden in diesem Zusammenhang die folgenden RFCs verabschiedet: Verwendung kryptografischer Algorithmen Vertraulichkeit: Die in RFC 2405 [MD98] spezifizierte Verwendung von DES im CBC-Modus wird aufgrund der zu geringen Schlüssellänge von DES mittlerweile nicht mehr empfohlen (diese Schwäche war im Jahr 1998, als der RFC verabschiedet wurde, allerdings bereits allgemein bekannt). RFC 2451 [PA98] definiert Format- und Verarbeitungsschritte für die Verwendung unterschiedlicher Blockchiffren im CBC-Modus mit ESP. Prinzipiell kann jede Blockchiffre mit einer Blockgröße von 64 bit gemäß diesem RFC eingesetzt werden. Explizit genannt werden die Algorithmen Blowfish, CAST-128, 3DES, IDEA und RC5. Der Initialisierungsvektor wird dabei in jedem Paket im Klartext übertragen, um Synchronisationsprobleme zu vermeiden (vergleiche hierzu Abschnitt 2.5). Der erste Intialisierungsvektor sollte zufällig gewählt werden, weitere Vektoren können durch den letzten berechneten Schlüsseltext gebildet werden. Nachrichtenauthentisierung: Für die Berechnung von Nachrichtenauthentisierungswerten für ESP werden die gleichen Algorithmen eingesetzt wie für AH (siehe hierzu den folgenden Abschnitt) Das AH-Protokoll Der in RFC 2402 [KA98a] spezifizierte Authentication (AH) stellt ein generisches Sicherheitsprotokoll dar, das für IP- Pakete die folgenden Sicherheitsdienste erbringt: Sicherheitsdienste von AH Nachrichtenauthentisierung: Für jedes zu schützende IP- Paket wird ein Nachrichtenauthentisierungswert berechnet und dem Paket hinzugefügt. Schutz vor Wiedereinspielung von IP-Paketen: Durch die Aufnahme einer Sequenznummer in den AH-Protokollkopf und Miteinbeziehung dieser Nummer in die Berechnung des MAC wird es dem Empfänger eines IP-Pakets ermöglicht, die Aktualität empfangener Pakete zu überprüfen.