3.1.2.Umsetzung einer Sicherheitsstrategie bei IPsec

Eine Sicherheitsstrategie bzw. Security Policy (SP) definiert, welche Sicherheitsdienste in welcher Art auf eine konkrete Verbindung angewendet werden sollen und kann somit als Grundlage eines IPsec-Systems betrachtet werden. Sämtliche Strategiespezifikationen werden, getrennt nach ein- und ausgehenden Verbindungen, in der Strategiedatenbank (Security Policy Database, SPD) verwaltet. Die dort enthaltenen Einträge legen für jedes einlangende und ausgehende IP-Paket fest, ob es verworfen, unbearbeitet weitergeleitet oder einer IPsec-Behandlung unterzogen wird. Im letztgenannten Fall definiert die SPD das Protokoll und den Modus.

Eine Sicherheitsassoziation bzw. Security Association (SA) dient der Realisierung einer Sicherheitsstrategie im konkreten Anlassfall und enthält u. a. folgende Informationen:

 IP-Adresse bzw. -Adressbereich des Empfänger(kreises), auf den sich die SA-Vereinbarungen beziehen

 Lebensdauer der SA (Zeit- und/oder Byte-basiert)

 Algorithmen, Schlüssel, Modi für AH oder ESP

 bei ESP mit Verschlüsselung und entsprechendem Blockchiffren-Betriebsmodus (z. B. CBC): Initialisierungsvektor

Zu beachten ist, dass eine SA nur für eine Übertragungsrichtung gültig ist. Soll eine bidirektionale Verbindung abgesichert werden, so sind entsprechende Ableitungen aus der SDP für beide Richtungen explizit vorzunehmen. Ebenso muss - bei gleichzeitiger Verwendung des AH- und ESP- Protokolls - für jedes Protokoll eine eigene SA abgeleitet werden. Die einzelnen SAs werden in einer Datenbank, der Security Association Database (SAD) gespeichert, wobei hier eine Trennung zwischen ein- und ausgehenden Verbindungen vorgenommen wird. Der Security Parameter Index (SPI), der Teil des AH- bzw. ESP-Headers ist, kommt nun zum Tragen, wenn der Empfänger ein solches Paket erhält. Der SPI wird aus diesem Paket extrahiert, anschließend wird in der SAD anhand dieses Zeigers nach der für diese Verbindung gültigen SA gesucht. Existiert dieser Eintrag, so kann er mit den dort gespeicherten Informationen bezüglich der Verfahren und aktuellen Schlüssel das Paket entschlüsseln und/oder authentifizieren. Wird jedoch kein Eintrag in der SAD gefunden, so muss aus der SDP eine SA abgeleitet werden. Dies kann auf manuelle Weise oder mittels Delegation an ein Schlüsselaustauschprotokoll, z. B. das Internet Key Exchange Protocol (IKE), erfolgen.

3.1.3. Kritikpunkte

Trotz der vielen Vorteile, die IPsec mit sich bringt, erkennen Bruce Schneier und Niels Ferguson im Zuge einer Evaluierung dieser Architektur auch einige Missstände [17]. Im Mittelpunkt der Kritik steht dabei die Komplexität des Systems, dessen Design viele unterschiedliche Kommunikationssituationen anhand einer Vielzahl von Optionen zu befriedigen versucht. Ein solches hochkomplexes System kann mit vorhandenen Methoden nur schwer analysiert und korrekt implementiert werden. Das Paper stellt weiters die Existenzberechtigung des AH-Protokolls und des Transportmodus in Frage. Der Transportmodus, der gegenüber dem Tunnelmodus keine funktionalen Vorteile mit sich bringt, hat zwar einen geringeren Paket-Overhead, dieser Nachteil kann jedoch durch die Anwendung eines Kompressionsalgorithmus beim Tunnelmodus wieder wettgemacht werden. Beim Einsatz des Tunnelmodus bietet das ESP-Protokoll keine schwächere Authentifizierung als das AH-Protokoll, da auch hier der ursprüngliche IP-Header sowie die Nutzdaten authentifiziert werden. Beim Wegfall des AH-Protokolls müsste jedoch auch eine Anpassung des ESP-Protokolls erfolgen, bei dem die Verschlüsselung und Authentifikation optionale Bestandteile sind. Da eine Verschlüsselung ohne zusätzliche Authentifikationsmechanismen sicherheitskritisch ist, wird hier empfohlen, die Authentifikation in das ESP-Protokoll zu integrieren und nur die Verschlüsselung optional verfügbar zu machen. Werden beide Dienste in Anspruch genommen, so erfolgt beim ESP- Protokoll die Authentifizierung nach der Verschlüsselung. Dies widerspricht dem Horton-Prinzip - authenticate what was meant, not what was said - bei dem die Authentifikation für den Klartext erfolgen sollte [18]. Als letzter Kritikpunkt aus dieser Evaluierung sei noch die Konfiguration der SAs aufgeführt, die auf unidirektionale Weise erfolgt. Einerseits erfolgt in den meisten Fällen eine bidirektionale Kommunikation zwischen den beteiligten Rechnern, andererseits ist auch eine asymmetrische Konfiguration mit unterschiedlichen Algorithmen nicht sicherheitsfördernd, sodass durch eine Bündelung der beiden unidirektionalen zu einer einzigen bidirektionalen SA die Konfiguration einfacher realisierbar wäre.

3.2. Transport Layer Security (TLS)

Das Transport Layer Security Protokoll (TLS), dessen aktuelle Version 1.2 im RFC 5246 [19] beschrieben ist, ist eine Weiterentwicklung der Secure Socket Layer-Spezifikation (SSL). Die grundlegende Funktionsweise ist bei beiden Protokollen zwar gleich, dennoch sind die Unterschiede signifikant genug, um eine Interoperabilität zwischen diesen Protokollen zu verhindern. Aus diesem Grund beinhaltet jede TLS-Version einen Mechanismus, um im Bedarfsfall auf eine SSL-Implementierung ausweichen zu können.

Das TLS-Protokoll hat zum vorrangigen Ziel, eine vertrauliche, verbindungsorientierte Ende- zu-Ende-Kommunikation mit gleichzeitiger Gewährleistung der Nachrichtenintegrität herzustellen, ebenso ist eine Authentifikation beider Kommunikationspartner möglich. Realisiert wird dieses Vorhaben mittels kryptografischer Maßnahmen wie der Verwendung asymmetrischer Verschlüsselungsverfahren und X.509-Zertifikaten, symmetrischer Sitzungsschlüssel sowie der Anwendung des HMAC-Verfahrens. Weitere Ziele von TLS betreffen die Interoperabilität der Applikationen, welche diesen Standard benutzen, eine Erweiterbarkeit in Bezug auf den Austausch bzw. die Integration neuer kryptografischer Verfahren dank eines modularen Designs sowie eine effiziente Vorgehensweise bezüglich eines Verbindungsaufbaus. Der letztgenannte Punkt wird bei TLS durch ein Sitzungsund Verbindungskonzept gelöst, bei dem zwar eine Sitzung mittels teurer, asymmetrischer Operationen etabliert werden muss, eine oder mehrere konkrete Verbindungen einer bestehenden Sitzung können jedoch mit relativ wenig Aufwand instanziiert werden.

Das TLS-Protokoll ist zwischen einem verbindungsorientierten Transportprotokoll (z. B. TCP) und einem Protokoll der Anwendungsschicht angesiedelt. TLS ist somit ein anwendungsorientiertes Protokoll, welches als Grundlage für die Implementierung vonseiten eines Anwendungsprotokolls verwendet werden muss. Eine Anwendung, wie etwa SIP, greift dabei auf die von TLS zur Verfügung gestellten Dienste über reservierte Portadressen zu.

Das TLS-Protokoll besteht aus zwei Schichten, deren Einordnung in Abbildung 3.2 ersichtlich ist. Zum einen handelt es sich um den an der Anwendungsschicht angrenzenden TLS Handshake Layer (Kapitel 3.2.1), der aus mehreren Subprotokollen besteht und für die Etablierung einer Sitzung verantwortlich ist. Darunter befindet sich der Record Layer (Kapitel 3.2.2), der für die Kapselung der Protokolle einer höheren Ebene zuständig ist.

3.2.1. TLS Handshake Protocol

Mit Hilfe des zustandsbehafteten TLS-Protokolls werden Sitzungen zwischen den Kommunikationspartnern etabliert, wobei auch mehrere Sitzungen zwischen einem Client zu einem oder mehreren Servern erlaubt sind. Die wesentliche Aufgabe des TLS Handshake Layers besteht darin, die notwendigen Informationen zur Berechnung des Sitzungs- und MAC-Schlüssels auf Client- und Serverseite zwischen den Kommunikationspartnern auszutauschen und konsistent zu halten. Der Austausch der Sitzungsinformationen mittels des TLS Handshake Protokolls erfolgt auf solche Weise, dass die Sicherheitsdienste Authentizität des Servers (optional auch die des Clients), Vertraulichkeit und Nachrichtenintegrität gewährleistet werden. Weitere Subprotokolle des TLS Handshake Layers sind - neben dem für den Sitzungsaufbau dienlichen TLS Handshake Protokoll - folgende drei Protokolle:

Abbildung 3.2.: Einordnung des TLS-Protokolls [16]

 Change Cipher Spec Protocol : Dieses Protokoll umfasst lediglich eine Nachricht in der Länge von einem Byte mit dem Wert 1. Ab dem Zeitpunkt, an dem eine solche Nachricht gesendet wird, erfolgt die weitere Kommunikation mit den soeben ausgehandelten Parametern.

 Alert Protocol : Dieses Protokoll ist zuständig für den Versand von Warnungen an den Kommunikationspartner. Neben der Beschreibung des Alarms (z. B. ein abgelaufenes Zertifikat oder ein inkorrekt empfangener MAC-Wert) wird in einer Alert-Nachricht auch mit angegeben, wie schwer der entsprechende Alarm wiegt. Möglich sind hierbei die beiden Werte 1 (warning) oder 2 (fatal). Beim Eintritt des zweiten Falls wird ein sofortiger Abbruch der Verbindung erzwungen, ebenso werden keine neuen Verbindungen für diese Sitzung eröffnet.

 Application Data Protocol : Zweck dieses Protokolls ist die transparente Weiterleitung der Anwendungsdaten an den darunterliegenden Record Layer.

Das TLS Handshake Protokoll ist verantwortlich für die Authentifizierung der Kommunikationspartner und...