Rechnernetze
Home Nach oben Stichworte

Encapsulating Security Payload

Der Header Encapsulating Security Payload (ESP) bietet verschiedene Sicherheitsdienste an, neben Verschlüsselung auch die Authentisierung, und kann in IPv4 und IPv6 verwendet werden. Da es neben dem Transport- auch den Tunnelmodus unterstützt, ist es im Prinzip universell einsetzbar.

Der ESP-Header wird hinter dem IP-Header und vor dem Header der oberen Transportschicht eingefügt.

ESP bietet die folgenden Sicherheitsdienste an:

  1. Vertraulichkeit,
  2. Datenquellenauthentisierung,
  3. Integrität bei verbindungsloser Kommunikation,
  4. Antireplay-Dienst,
  5. beschränkte Verkehrsflussvertraulichkeit.

Diese Dienste hängen teilweise voneinander ab. Der Standard schreibt vor, dass mindestens einer der Dienste Vertraulichkeit oder Authentisierung verwendet werden muss. 

Paketformat der Encapsulating Security Payload

ESP-Pakete werden durch den Wert 50 im Nextheader-Feld des vorhergehenden Pakets gekennzeichnet. Das ESP-Paket hat folgenden Aufbau:

Hierbei bedeuten die einzelnen Werte folgendes:

Security Parameters Index (SPI)
Ein 32 Bit-Wert, der in Kombination mit der Zieladresse und dem Protokoll ESP eindeutig die SA für dieses Datagramm identifiziert. Gewisse Werte (1..255) dürfen in der Regel nicht vergeben werden, bzw. werden nur lokal (0) verwendet. Der Wert des SPI wird von dem Zielrechner beim Aufbau der SA festgelegt. Dieser Wert kommt in jedem ESP-Paket vor.
Sequenznummer
Ein 32 Bit-Wert, der als Antireplay-Wert benutzt werden kann. Der Sender muss diesen Wert einfügen und beginnend bei 1 inkrementieren; der Empfänger kann diesen Wert auswerten, braucht es aber nicht. Der Wert darf niemals über den Höchstwert 232-1 inkrementiert werden. Dieser Wert kommt in jedem ESP-Paket vor.
Payload-Data
Die Daten, deren Typ im Nextheader-Feld beschrieben werden. Wenn diese Daten verschlüsselt sind und einen Initialisierungsvektor (Synchronisationsdaten) benötigen (z.B. bei DES-CBC), so wird dieser explizit angegeben. Ein RFC, welches dieses Verschlüsselungsverfahren beschreibt, muss eindeutig festlegen, wie die Synchronisationsdaten aus dem Payload-Datenfeld oder dem ESP-Header gewonnen werden können. Dieser Wert kommt in jedem ESP-Paket vor.
Padding
Paddingdaten haben keine Bedeutung für die übertragenen Payload-Daten. Sie füllen jedoch das Paket auf die gewünscht Länge auf, werden bei Blockchiffren und ähnlichen Verschlüsselungsverfahren verwendet und können die wahre Länge eines Datenfeldes verschleiern. Dieser Wert ist optional, kann also die Länge null haben. Paddingfelder müssen mit explizit oder implizit definierten Werten (1,2, ...) versehen werden. 
Pad-Length
Anzahl der Padding-Oktette. Der Wert beträgt 0-255 und kommt in jedem ESP-Paket vor.
Next Header
Gibt den Typ der Payload-Daten an, z.B. Transportprotokoll oder einen Erweiterungsheader in IPv6. Dieser Wert kommt in jedem ESP-Header vor.
Authentication Data
Dient der Authentisierung des ESP-Feldes (ohne die Authentisierungsdaten). Die Länge ist abhängig von dem Authentisierungsalgorithmus. Dieser Wert ist optional.

Anordnung des ESP-Headers

Im Transportmodus wird ein ESP-Header nach dem IP-Header und vor den entsprechenden Daten der oberen Schichten, z.B. TCP oder auch ICMP, angeordnet. Wenn ein vollständiges IP-Paket verschlüsselt werden soll, so wird der ESP-Header entsprechend vor diesem inneren IP-Header angeordnet. Das folgende Beispiel zeigt die Einkapselung eines TCP-Pakets.

In IPv6 kann der Destination-Options-Header an verschiedenen Stellen stehen. Um diesen ebenfalls mitzuverschlüsseln kann es sinnvoll sein, ihn hinter den ESP-Header zu stellen. Es dürfen allerdings mehrere Destination-Options-Header vorkommen, so dass ein Destination-Options-Header an verschiedenen Stellen stehen kann.

Im Tunnelmodus enthält der innere Header die Zieladressen, während der äußere IP-Header eine andere Adresse enthalten kann, z.B. die eines Security-Gateways. Für typische IPv4- und IPv6-Datagramme erhält man die folgende Anordnung des ESP-Headers im Tunnelmodus:

Das Bild zeigt deutlich, dass im Tunnelmodus der gesamte innere IP-Header, einschließlich der Zieladresse, verschlüsselt wird, so dass auf  diese Weise auch die Verkehrsflussvertraulichkeit unterstützt wird.

Funktionen beim Senden eines ESP-Pakets 

Eine ESP-Implementierung muss mindestens DES-CBC zur Verschlüsselung anbieten; der Initialisierungsvektor muss im Payloadfeld abgelegt werden. Außerdem wird der NULL-Algorithmus, also keine Verschlüsselung, gefordert. Darüber hinaus sind jedoch weitere Verschlüsselungsverfahren möglich, so dass insbesondere zukünftige Erweiterungen einfach eingebracht werden können. Es müssen jedoch sämtliche Parameter für die Entschlüsselung in einem Block abgelegt werden, entweder als expliziter Wert im Payloadfeld oder aus dem ESP-Header ableitbar.

Punkt-zu-Punkt-Kommunikation kann mit Hilfe eines schlüsselbasierten Message Authentication Codes wie DES oder mit Hashfunktionen wie MD5 oder SHA-1 authentifiziert werden; die letzten beiden Algorithmen müssen implementiert sein. Darüber hinaus ist auch die Null-Authentisierung vorgeschrieben. Wird ESP eingesetzt, so muss mindestens verschlüsselt oder authentisiert werden, oder beides.

Nachdem ein ausgehendes Paket aufgrund eines entsprechenden Eintrags in der Security Policy Database als ESP-Paket erkannt wurde, wird zunächst das entsprechende Paket im Klartext konstruiert. Dieses besteht beim Transportmodus aus dem höheren Protokoll, beim Tunnelmodus aus dem gesamten IP-Datagramm einschließlich IP-Header, an welches Padding-Bytes, Pad-Länge und Next-Header-Feld angehängt werden. Verlangt die SA Verschlüsselung, so wird dieses Paket mit dem gewählten Algorithmus verschlüsselt. Explizite oder implizite Verschlüsselungsparameter wie ein Initialisierungsvektor beim DES-CBC werden in das Payloadfeld an festgelegter Stelle einfügt oder aus dem ESP-Header nach einem festgelegten Verfahren berechnet.

Grundsätzlich wird der Sequenzzähler inkrementiert und in das entsprechende Feld übernommen. Ein Überlauf des Zählers führt zu einem Alarm und Löschung der SA.

Verlangt die SA Authentisierung, so berechnet der Sender den Integrity Check Value (ICV) aus diesem Paket ohne die Authentisierungsdaten und fügt den ICV in das Feld für die Authentisierungsdaten ein. Derartige Pakete können gegebenenfalls vom Sender bei IPv6 fragmentiert werden, müssen jedoch vor einer Entschlüsselung wieder reassembliert werden.

Funktionen beim Empfangen eines ESP-Pakets

Nachdem ein eingehendes Paket aufgrund eines entsprechenden Eintrags in der Security Policy Database als ESP-Paket erkannt wurde, wird zunächst das Sequenznummernfeld überprüft, wenn die SA das vorschreibt. Da eingehende Pakete in beliebiger Reihenfolge eintreffen können, wird ein Fensterverfahren vorgeschlagen, welches 32 bis 64 Sequenznummern verifiziert und auf Duplikate überprüft. Wird ein dupliziertes Paket erkannt, so wird dieses in einer Logdatei protokolliert.

Als nächstes wird - wenn durch die SA festgelegt - Authentisierung durchgeführt, indem das ESP-Paket ohne Authentisierungsdaten mit dem vereinbarten Algorithmus geprüft und gegen die Authentisierungsdaten abgeglichen wird. Ein Fehler wird in einer Logdatei unter Angabe von SPI, Empfangszeit, Quell- und Zieladresse und Sequenznummer protokolliert.

Als nächstes wird - wenn durch die SA festgelegt - Dechiffrierung durchgeführt, indem das ESP-Paket ohne die Authentisierungsdaten mit dem vereinbarten Algorithmus entschlüsselt wird. Aus dem Klartext werden zunächst die Paddingdaten extrahiert und überprüft (1,2,.. bei impliziten Daten). Danach wird das ursprüngliche Paket einschließlich IP-Header (auch im Tunnelmodus) restauriert und weiter an IP geleitetet, welches den Datenteil dem Transportprotokoll übergibt oder im Tunnelmodus als neues IP-Paket weiterleitet.

Der Standard nennt zu protokollierende Fehler auditable events, die in der Regel in einer Logdatei protokolliert werden. Es wird nicht verlangt, dass jedes System Fehler protokolliert, jedoch wenn es dieses durchführt, so müssen die Mechanismen zum Protokollieren von AH-Fehlern vorgesehen werden und der Administrator muss dieses ein- bzw. ausschalten können. Im Falle eines derartigen Fehlers ist der Empfänger nicht verpflichtet, diesen an den Absender zu melden, um auf diese Weise beispielsweise die Gefahr von Denial-of-Service-Angriffen zu verhindern.