IP Encapsulating Security Payload (ESP), spezifiziert in RFC 4303, ist das zweite IPsec-Protokoll. Im Gegensatz zu dem in About Security #89 vorgestellten IP Authentication Header ist hiermit zusätzlich zur Authentifizierung und Sicherstellung der Integrität auch die Sicherstellung der Vertraulichkeit durch Verschlüsselung der Daten möglich.

Header des IP-Encapsulating-Security-Payload-(ESP-)Protokolls

Schutzmaßnahmen: Verschlüsselt, Signiert

• Security Parameter Index (SPI)
  definiert zusammen mit der IP-Adresse und dem IPsec-Protokoll die Sicherheitsassoziation (Security Association).
  Diese legt die von den IPsec-Protokollen verwendeten Parameter fest, s.u.
• Sequenznummer
  zur Verhinderung von Replay-Angriffen, s. About Security #89
• Payload
  der Bereich, der die verschlüsselten Nutzdaten enthält:
  • Initialisierungsvektor (Initialization Vector, IV)
    ist der Initialisierungsvektor für den im Cipher-Block-Chaining-Modus eingesetzten symmetrischen Verschlüsselungsalgorithmus.
    Die Länge ist abhängig vom eingesetzten Algorithmus und beträgt z.B. im Fall von 3DES 64 Bit.
  • Daten
    die eigentlichen Daten, verschlüsselt mit dem eingesetzten Algorithmus
• Padding (Füllbytes)
  dient zum Auffüllen der Daten bis zur nächsten Blockgrenze des Blockalgorithmus, die Länge liegt zwischen 0 und 255 Byte.
• Padding Length
  gibt die Länge des verwendeten Paddings an, um es nach der Entschlüsselung entfernen zu können.
• Next Header
  definiert das Protokoll der im Paket übertragenen Daten.
  Im Transportmodus enthält es die Protokollnummer des jeweiligen höheren Protokolls, im Tunnelmodus mit IPv4 eine 4.
• Integrity Check Value (ICV)
  enthält ggf. die Authentifizierungsdaten.
  Der ICV wird erst nach abgeschlossener Verschlüsselung berechnet, um beim Empfänger bei fehlgeschlagener Authentifizierung die Entschlüsselung zu sparen.
  Im Gegensatz zum IP-Authentication-Header-Protokoll wird der IP-Header nicht in die Berechnung des ICV einbezogen. Geschützt werden nur der ESP-Header und die verschlüsselten Nutzdaten. Dies ermöglich prinzipiell den Einsatz von Network Adress Translation (NAT), da eine nachträgliche Änderung der IP-Adressen nicht zur Ungültigkeit des ICV führt.

Sicherheitsassoziation und Security Policy

Die Sicherheitsassoziation (Security Association, SA, spezifiziert in RFC 4301) legt die von den IPsec-Protokollen zu verwendenden Parameter wie Verschlüsselungs- und Authentifizierungsalgorithmus und deren Schlüssel etc. sowie weitere Informationen wie z.B. die Lebensdauer der SA und die Betriebsart (Transport- oder Tunnelmodus) fest. Alle Sicherheitsassoziationen werden in der so genannte Security Association Database (SAD) gespeichert. Jeder Eintrag enthält mindestens folgende Daten:

• Security Parameter Index (SPI)
  ein vom Empfänger gewählter Wert zur eindeutigen Identifizierung der SA. Bei ausgehenden Verbindungen wird der Wert für den Aufbau des AH- bzw. ESP-Headers verwendet. Bei eingehenden Verbindungen wird darüber die passende SA bestimmt.
• Sequence Number Counter
  ist ein 64-Bit-Zähler für die aktuelle Sequenznummer.
• Sequence Counter Overflow
  ist ein Flag, das die Regeln im Fall eines Sequenznummerüberlaufs festlegt.
• Anti-Replay-Empfangsfenster
• AH-Authentifizierungsalgorithmus, Schlüssel etc. (nur wenn erforderlich)
• ESP-Verschlüsselungs- und -Authentifizierungsalgorithmus sowie deren Schlüssel etc. (nur wenn erforderlich)
• Lebensdauer der Sicherheitsassoziation
• Betriebsart (Transport- oder Tunnelmodus)
• Quell- und Zieladresse für den Tunnelmodus (nur wenn erforderlich)
• einige weitere Felder, auf die hier nicht eingegangen werden soll

Während die Sicherheitsassoziation festlegt, wie die Daten geschützt werden, legt die Security Policy (SP, spezifiziert in RFC 4301) fest, welche/wann Daten geschützt werden.

Die Security Policies werden in der Security Policy Database (SPD) gespeichert. Für jedes die IPsec-Grenze passierende Paket (egal ob aus- oder eingehend) wird in der SPD nachgesehen, wie das Paket zu behandeln ist. Dabei sind drei Aktionen möglich:

• DISCARD, das Paket darf die IPsec-Grenze nicht passieren und wird verworfen
• BYPASS, das Paket darf die IPsec-Grenze unverändert passieren
• PROTECT, das Paket wird entsprechend der zuständigen SA geändert.

Die Auswahl der anzuwendenden Security Policy erfolgt auf Grundlage der lokalen und entfernten IP-Adressen und des verwendeten Protokolls. So könnte z.B. die HTTP-Verbindung zwischen zwei ganz bestimmten Rechnern mit IPsec geschützt werden, während alle anderen HTTP-Verbindungen ungeschützt bleiben.

In der nächsten Folge wird das für den Schlüsselaustausch verwendete Internet Key Exchange Protocol (IKEv2) beschrieben.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "VPN – Virtuelle Private Netze"

• About Security #88: Virtuelle Private Netze – Grundlagen
• About Security #89: Virtuelle Private Netze – IPsec (1)
• About Security #90: Virtuelle Private Netze - IPsec (2)
• About Security #91: Virtuelle Private Netze – IKEv2 (1)
• About Security #92: Virtuelle Private Netze – IKEv2 (2)
• About Security #93: Virtuelle Private Netze – IKEv2 (3)
• About Security #94: Virtuelle Private Netze – Beispiel IKEv2
• About Security #95: Virtuelle Private Netze – IPsec anschaulich
• About Security #96: Virtuelle Private Netze – PPTP
• About Security #97: Virtuelle Private Netze – TLS
• About Security #98: Virtuelle Private Netze – OpenVPN
• About Security #99: Virtuelle Private Netze – Fazit