Rechnernetze

Security Associations

RFC 2401 führt den Begriff Sicherheitsverbindung (security association, auch Sicherheitsassoziation, SA) ein, um Umfang und Eigenschaften der gesicherten Datenübertragung zu beschreiben. (Der Begriff Assoziation stammt aus dem ISO/OSI-Basisferenzmodell und wird dort synonym für Verbindung benutzt). Eine Sicherheitsverbindung ist eine Simplexverbindung für einen Dienst wie Authentisierung (durch AH) oder Verschlüsselung (durch ESP), die durch die Parameter

	Sicherheitsparameterindex (Security Parameter Index, SPI),
	IP-Zieladresse (*IP Destination Address*),
	Sicherheitsdienstkennzeichnung (*Security protocol identifier* (AH oder ESP)).

gekennzeichnet ist. Werden mehrere Sicherheitsdienste (AH und ESP) eingesetzt oder sollen Duplexverbindungen geschützt werden, so müssen mehrere Sicherheitsverbindungen aufgebaut werden. Als Zieladresse sind Unicast- oder Multicastadressen zulässig, wenngleich das RFC 2401 sich auf Unicastadressen konzentriert.

Eine Sicherheitsverbindung im Transportmodus verbindet zwei Hosts, wobei auch ein Transitsystem als endgültiger Empfänger von Datagrammen (z.B. ICMP-Nachrichten) ein Host sein kann. In IPv4 stehen die Sicherheitsheader direkt zwischen dem IPv4-Header (mit Optionen) und dem Header der Anwendungsschicht. Zwischen Transitsystemen und Endsystemen können Sicherheitsverbindungen im Tunnelmodus betrieben werden. Im Tunnelmodus wird ein äußerer und ein innerer IP-Header verwendet, zwischen denen der Sicherheitsheader eingefügt ist. Während der äußerer Header das Ende des Tunnels adressiert, enthält der innere Header die eigentliche Zieladresse.

Die Kombination von Sicherheitsverbindungen wird technisch durch die Verschachtelung der jeweiligen Sicherheitsdienste erreicht. Eine solche Kombination von Sicherheitsverbindungen wird als SA-Bündel (SA bundle) bezeichnet. Man unterscheidet zwei prinzipielle Konzepte:

Unter Transport Adjacency versteht man die Verwendungen von zwei Sicherheitsverbindungen in einem Datagramm; es ist nur jeweils eine AH- und eine ESP-Sicherheitsverbindungen sinnvoll. Da das Datagramm beim gleichen Empfänger aufläuft - es gibt nur eine IP-Zieladresse - sind Anfangs- und Endpunkte gleich. Als Reihenfolge der SAs wird IP-AH-ESP empfohlen, so dass die Authentisierung auf Teilen des IP-Headers sowie auf ESP angewendet werden kann.

Eine iterierte getunnelte Verbindung (iterated tunneling) verwendet mehrere Datagramme, die gegebenenfalls ganze Datagramme enthalten. Diese können somit mehrere Zieladressen enthalten, so dass mehrere Kombinationen denkbar sind:

Beide Endpunkte aller Sicherheitsverbindungen sind gleich.

Ein Endpunkt aller Sicherheitsverbindungen ist gleich, die anderen verschieden.

Alle Endpunkt der Sicherheitsverbindungen sind verschieden.

Die Reihenfolge der SAs ist hier beliebig, abhängig von den jeweiligen Sicherheitsanforderungen.

Es können - abhängig von den Endpunkten - verschiedene Kombinationen von Sicherheitsverbindungen erstellt werden. Beispielsweise können zwischen Routern verschlüsselte Tunnelverbindungen aufgebaut werden, welche zu verschiedenen Endsystemen in den jeweiligen lokalen Netzen ungeschützte oder auch authentisierte Verbindungen betreiben. Durch die Verwendung verschachtelter Sicherheitsverbindungen kann jeder Grad an Sicherheit erreicht werden. Im Prinzip kann beispielsweise die Verschlüsselungsstärke auch durch die Verwendung verschachtelter ESP-Header verbessert werden (Produktchiffren), wenngleich dieses Verfahren u.U. nicht die erhoffte zusätzliche Sicherheit bringt (s. a. Meet-in-the-Middle Angriff).

Es werden vier Basiskonfigurationen von SAs definiert, welche unterstützt werden müssen; weitere können optional hinzugefügt werden.

Sicherung der Ende-zu-Ende-Verbindung zweier Hosts im Transport- oder Tunnelmodus.
Sicherung der Gateway-Gateway-Verbindung im Tunnelmodus.
Sicherung der Ende-zu-Ende-Verbindung zweier Hosts im Transport- oder Tunnelmodus sowie gleichzeitige Sicherung der Gateway-Gateway-Verbindung im Tunnelmodus.
Zugang zu einem lokalen Netz über externe Verbindung wie Internet oder Einwahlverbindung.

SA und Schlüssel-Management

IPsec gestattet manuelle und automatisierte Schlüsselverteilung und SA-Management, wenngleich manuelles Vorgehen durchaus mit einigen Nachteilen verbunden ist. So kann der Antireplaydienst nicht bei manuellem SA-Management eingesetzt werden, weil es nicht möglich ist, die Zähler zu synchronisieren.

Manuelles Management kann nur in kleinen, lokal beschränkten Netzen eingesetzt werden oder wenn manuell die Kommunikation zwischen zwei oder wenigen Security Gateways mit Tunneling aufgebaut werden soll. Ansonsten ist aus Sicherheits- und Effizienzgründen automatisches Management sinnvoller.

Automatisches SA- und Schlüsselmanagement wird benötigt, wenn der Antireplaydienst verwendet werden soll und wenn Anwender spontan neue SAs kreieren und benutzen wollen. IPsec führt einen Standard zum Schlüsselmanagement ein, erlaubt jedoch die Verwendung weiterer Standards. Mit Hilfe dieser Verfahren werden insbesondere gemeinsame Schlüssel erzeugt, wobei Regelungen getroffen sind, wie diese aus einem einzelnen Bitstring, der als "Masterkey" verwendet wird, abzuleiten sind.

IPsec Standards zum Schlüsselmanagement sind

	IKE: The Internet Key Exchange, RFC 2409.
	ISAKMP: Internet Security Association an Key Management Protocol, RFC 2408.
	The Oakley Key Determination Protocol, RFC 2412.
	The Internet IP Security Domain of Interpretation for ISAKMP, RFC 2407.

Verarbeitung von IP-Datagrammen unter IPsec

Soll ein Datagramm gesendet werden, so ist zunächst ein entsprechender Eintrag in der SPD (Security Policy Database) zu suchen; sollte kein passender Eintrag existieren, so ist das Datagramm zu verwerfen. Sollte festgelegt sein, dass ein Datagramm nicht durch IPsec geschützt werden soll, so wird dieses unverändert weitergereicht.

Außer dem Time to Live-Feld (und damit die Prüfsumme) wird im Tunnel-Modus der innere Header (einschließlich irgendwelcher Erweiterungsheader) nicht verändert. Es können äußerer und innerer Header bezüglich Version (IPv4 und IPv6) verschieden sein. Gegebenenfalls muss ein Paket fragmentiert werden, wenn es zusammen mit den jeweiligen Erweiterungsheadern vorgegebene Größen überschreitet. Danach wird entsprechend der gewählten SA die Verschlüsselung und Authentisierung durchgeführt und die entsprechenden Header angelegt und mit den berechneten Werten versehen. Dann kann das Paket an den nächsten Router gesendet werden.

Eingehender Verkehr wird zunächst reassembliert und entsprechend der jeweiligen Parameter einer SA in der SA-Database zugeordnet, woraufhin das Paket authentisiert und entschlüsselt werden kann. Danach muss anhand eines entsprechenden Eintrags in der SPD überprüft werden, ob die Sicherheitsstrategie für dieses Paket eingehalten wurde. Dabei sind u.U. mehrere Sicherheitsstrategien zu überprüfen, ehe eine passende gefunden wird. Das derart überprüfte und entschlüsselte Paket kann dann an die Anwendungsschicht oder an einen anderen Router oder ein Host weitergereicht werden, wobei gegebenenfalls Information in bearbeiteten Headern wie Absender oder Prüfungsreihenfolge in folgenden IPsec-Prozessen oder Firewalls benötigt werden könnte, so dass sie entsprechend zu behandeln ist.

Ein Sonderfall stellen ICMP-Nachrichten dar. Diese sollten im wesentlichen wie normale IPsec-Datagramme behandelt werden, wobei in der Regel der Tunnel-Modus angewendet werden sollte, um die Absender- und Empfängeradresse unverändert zu belassen. Der Standard sieht auch ausdrücklich vor, dass IPsec so konfigurierbar sein muss, das auch unauthentifizierte oder unverschlüsselte ICMP-Nachrichten verarbeitet werden können. ICMP-Nachrichten zur Bestimmung der maximalen Paketlänge auf einem Pfad (PMTU, path maximum transport unit) müssen jedoch gesondert behandelt werden, da sie wichtige Information über maximale Paketgrößen liefern. Sollte die Information in der ICMP-Nachricht zur Bestimmung des sendenden Routers nicht ausreichen, weil der Header zu viele IPsec-Daten enthält, so muss der entsprechende Router aufgefordert werden, genauere Informationen zu senden.

Bei der Berechnung der PMTU muss die Zusatzinformation durch die IPsec-Header berücksichtigt werden. Um nicht zu kleine Datagramme zu erhalten, erlaubt der Standard ausdrücklich, dass IPsec erst nach der Authentifizierung bzw. Verschlüsselung eine Fragmentierung durchführt.

Werden die Sicherheitsanforderungen abhängig von der Wichtigkeit einer Nachricht differenziert, so spricht man von Multi-Level Security (MLS). Gegebenenfalls könnte der Grad der geforderten Sicherheit als zusätzlicher Parameter zu Spezifizierung einer SA verwendet werden, was zusätzliche Bearbeitung bei zu sendenden und empfangenen Paketen erforderlich machen würde.

IPsec erfordert eine relativ aufwendige Behandlung von Datagrammen, wobei neben zusätzlicher Bearbeitungszeit auch noch zusätzlicher Speicher für die Algorithmen und die Sicherheitsdatenbanken benötigt wird; letzterer ist in der Regel besonders gegen absichtliche Verfälschung zu schützen. Dennoch wird nicht erwartet, dass für einen Host der Bearbeitungszeitaufwand inakzeptabel hoch wird, während Router bzw. Security Gateways in der Regel mit spezieller Hardware ausgestatteten werden können und sollten. Zusätzlich wird auch die Bandbreitenbelastung zunehmen, wobei zusätzliche Verzögerungen beim Aufbau einer SA beispielsweise TCP veranlassen könnte, mehr als nötig SYN-Pakete zu senden oder den Verbindungsaufbau abzubrechen. UDP dürfte hier jedoch weniger Probleme bereiten. Werden Daten über eine langsame Datenverbindung geschickt, wie eine Telefonleitung, so kann IPsec wegen der zur Zeit noch nicht unterstützten Kompression zu sehr langen Verbindungszeiten führen. Aus diesem Grunde sollte Kompression bereits von der Anwendungsschicht durchgeführt werden; erfahrungsgemäß können verschlüsselte Daten kaum oder gar nicht komprimiert werden, da sie keine sich wiederholenden Strukturen besitzen, welche üblicherweise im Klartext enthalten sind.