IPsec-Grundlagen

Sicherheitszuordnungen

Eine Security Association (SA) ist eine unidirektionale Vereinbarung zwischen den VPN-Teilnehmern in Bezug auf die Methoden und Parameter, die bei der Sicherung eines Kommunikationskanals verwendet werden sollen. Eine vollständige bidirektionale Kommunikation erfordert mindestens zwei SAs, eine für jede Richtung. Über den SA kann ein IPsec-Tunnel die folgenden Sicherheitsfunktionen bereitstellen:

• Datenschutz (durch Verschlüsselung)

• Inhaltsintegrität (durch Datenauthentifizierung)

• Absenderauthentifizierung und – bei Verwendung von Zertifikaten – Nichtrepudiation (durch Datenursprungsauthentifizierung)

Welche Sicherheitsfunktionen Sie einsetzen, hängt von Ihren Anforderungen ab. Wenn Sie nur die IP-Paketquelle und die Inhaltsintegrität authentifizieren müssen, können Sie das Paket ohne Verschlüsselung authentifizieren. Wenn Es hingegen nur um die Wahrung der Privatsphäre geht, können Sie das Paket verschlüsseln, ohne Authentifizierungsmechanismen anzuwenden. Optional können Sie das Paket verschlüsseln und authentifizieren. Die meisten Netzwerksicherheits-Designer entscheiden sich dafür, ihren VPN-Datenverkehr zu verschlüsseln, zu authentifizieren und erneut zu schützen.

Ein IPsec-Tunnel besteht aus einem Paar unidirektionaler SAs – einer SA für jede Richtung des Tunnels –, die den Sicherheitsparameterindex (SPI), die Ziel-IP-Adresse und das Sicherheitsprotokoll (Authentication Header [AH] oder Encapsulating Security Payload [ESP] angeben. Eine SA gruppiert die folgenden Komponenten zur Sicherung der Kommunikation:

• Sicherheitsalgorithmen und -schlüssel.

• Protokollmodus, entweder Transport oder Tunnel. Junos OS-Geräte verwenden immer den Tunnelmodus. (Siehe Paketverarbeitung im Tunnelmodus.)

• Schlüsselverwaltungsmethode, entweder manueller Schlüssel oder AutoKey-IKE.

• SA-Lebensdauer.

Für eingehenden Datenverkehr sucht Junos OS die SA mithilfe des folgenden Triplets:

• Ziel-IP-Adresse.

• Sicherheitsprotokoll, entweder AH oder ESP.

• Security Parameter Index (SPI)-Wert.

Für ausgehenden VPN-Datenverkehr ruft die Richtlinie die SA auf, die mit dem VPN-Tunnel verknüpft ist.

Manueller Schlüssel

Mit manuellen Schlüsseln konfigurieren Administratoren an beiden Enden eines Tunnels alle Sicherheitsparameter. Dies ist eine praktikable Technik für kleine, statische Netzwerke, in denen die Verteilung, Wartung und Verfolgung von Schlüsseln nicht schwierig sind. Die sichere Verteilung manueller Konfigurationen über große Entfernungen ist jedoch mit Sicherheitsproblemen verbunden. Abgesehen von der persönlichen Übergabe der Schlüssel können Sie nicht ganz sicher sein, dass die Schlüssel während der Übertragung nicht kompromittiert wurden. Außerdem müssen Sie, wenn Sie den Schlüssel ändern möchten, mit den gleichen Sicherheitsproblemen konfrontiert werden, wie bei der ersten Verteilung.

AutoKey-IKE

Wenn Sie zahlreiche Tunnel erstellen und verwalten müssen, benötigen Sie eine Methode, mit der Sie nicht jedes Element manuell konfigurieren müssen. IPsec unterstützt die automatisierte Generierung und Aushandlung von Schlüsseln und Sicherheitszuordnungen mithilfe des Internet Key Exchange (IKE)-Protokolls. Junos OS bezieht sich auf eine solche automatisierte Tunnel-Aushandlung wie AutoKey IKE und unterstützt AutoKey-IKE mit vorinstallierten Schlüsseln und AutoKey-IKE mit Zertifikaten.

• AutoKey-IKE mit vorab genutzten Schlüsseln: Mithilfe von AutoKey-IKE mit vorab genutzten Schlüsseln zur Authentifizierung der Teilnehmer in einer IKE-Sitzung muss jede Seite den vorab gemeinsam genutzten Schlüssel konfigurieren und sicher austauschen. In dieser Hinsicht ist die Frage der sicheren Schlüsselverteilung dasselbe wie bei manuellen Schlüsseln. Nach der Verteilung kann ein Autokey jedoch im Gegensatz zu einem manuellen Schlüssel seine Schlüssel automatisch in vorgegebenen Intervallen mithilfe des IKE-Protokolls ändern. Häufig wechselnde Schlüssel verbessern die Sicherheit erheblich, und automatisch werden die Verantwortlichkeiten für das Schlüsselmanagement erheblich reduziert. Durch das Ändern der Schlüssel erhöht sich jedoch der Datenverkehrsaufwand. daher kann ein allzu häufiger Wechsel der Schlüssel die Effizienz der Datenübertragung reduzieren.

  Ein vorinstallierter Schlüssel ist ein Schlüssel sowohl für die Ver- als auch für die Entschlüsselung, die beide Teilnehmer vor dem Starten der Kommunikation haben müssen.

• AutoKey-IKE mit Zertifikaten: Bei der Verwendung von Zertifikaten zur Authentifizierung der Teilnehmer während einer AutoKey-IKE-Aushandlung generiert jede Seite ein öffentlich-privates Schlüsselpaar und erwirbt ein Zertifikat. Solange die ausstellende Zertifizierungsstelle von beiden Seiten vertrauenswürdig ist, können die Teilnehmer den öffentlichen Schlüssel des Peers abrufen und die Signatur des Peers überprüfen. Es besteht keine Notwendigkeit, die Schlüssel und SAs im Auge zu behalten. IKE tut dies automatisch.

Diffie-Hellman Exchange

Ein Diffie-Hellman (DH)-Austausch ermöglicht es den Teilnehmern, einen gemeinsamen geheimen Wert zu erzielen. Die Stärke der Technik ist, dass es den Teilnehmern ermöglicht, den geheimen Wert über ein ungesichertes Medium zu schaffen, ohne den geheimen Wert durch die Leitung zu geben. Die Größe des Primmoduls, das in der Berechnung jeder Gruppe verwendet wird, unterscheidet sich, wie in der folgenden Tabelle dargestellt. Der Austausch von Diffie Hellman (DH) kann entweder in Software oder hardwarebetrieben werden. Wenn diese Exchange-Operationen in Hardware ausgeführt werden, verwenden wir QuickAssist Technology (QAT) Kryptografie. Im Folgenden Tabelle 1 werden verschiedene Diffie Hellman (DH)-Gruppen aufgeführt und angegeben, ob der für diese Gruppe durchgeführte Vorgang in der Hardware oder in der Software erfolgt.

Tabelle 1: Diffie Hellman (DH) Gruppen und deren Austauschoperationen durchgeführt

Diffie-Hellman (DH) Gruppe	Prime-Modulgröße
DH-Gruppe 1	768-bit
DH-Gruppe 2	102-bit
DH-Gruppe 5	1536-bit
DH-Gruppe 14	2048-bit
DH-Gruppe 15	3072-bit
DH-Gruppe 16	4096-bit
DH-Gruppe 19	Elliptische Kurve mit 256 Bit
DH-Gruppe 20	Elliptische 384-Bit-Kurve
DH-Gruppe 21	Elliptische 521-Bit-Kurve
DH-Gruppe 24	2048-Bit mit 256-Bit-Untergruppe für prime order

Ab Junos OS Version 19.1R1 unterstützen Geräte der SRX-Serie DH-Gruppen 15, 16 und 21.

Ab Junos OS Version 20.3R1 unterstützen vSRX-Instanzen mit installierten Junos-ike-Paketen DH-Gruppen 15, 16 und 21.

Wir empfehlen die Verwendung der DH-Gruppen 1, 2 und 5 nicht.

Da das Modul für jede DH-Gruppe eine unterschiedliche Größe hat, müssen die Teilnehmer zustimmen, dieselbe Gruppe zu verwenden.

IPsec-Authentifizierungsalgorithmen (AH-Protokoll)

Das AH-Protokoll (Authentication Header) bietet eine Möglichkeit, die Echtheit und Integrität des Inhalts und der Herkunft eines Pakets zu überprüfen. Sie können das Paket durch die Prüfsumme authentifizieren, die durch einen Hash Message Authentication Code (HMAC) berechnet wird, indem Sie einen geheimen Schlüssel und entweder MD5- oder SHA-Hashfunktionen verwenden.

• Message Digest 5 (MD5): Ein Algorithmus, der aus einer Nachricht beliebiger Länge und einem 16-Byte-Schlüssel einen 128-Bit-Hash (auch als digitale Signatur oder Message Digest bezeichnet) erzeugt. Der resultierende Hash wird wie ein Fingerabdruck der Eingabe verwendet, um die Echtheit und Integrität von Inhalten und Quellen zu überprüfen.

• Secure Hash Algorithm (SHA): Ein Algorithmus, der aus einer Nachricht von beliebiger Länge und einem 20-Byte-Schlüssel einen 160-Bit-Hash erzeugt. Es wird allgemein aufgrund der größeren Hashes, die es erzeugt, als sicherer als MD5 angesehen. Da die Rechenverarbeitung im ASIC erfolgt, sind die Leistungskosten vernachlässigbar.

Weitere Informationen zu MD5-Hashing-Algorithmen finden Sie unter RFC 1321 und RFC 2403. Weitere Informationen zu SHA-Hashing-Algorithmen finden Sie unter RFC 2404. Weitere Informationen zu HMAC finden Sie unter RFC 2104.

IPsec-Verschlüsselungsalgorithmen (ESP-Protokoll)

Das Encapsulating Security Payload (ESP)-Protokoll bietet ein Mittel, um Datenschutz (Verschlüsselung), Quellauthentifizierung und Inhaltsintegrität (Authentifizierung) zu gewährleisten. ESP im Tunnelmodus verkapselt das gesamte IP-Paket (Header und Payload) und fügt dann einen neuen IP-Header an das jetzt verschlüsselte Paket an. Dieser neue IP-Header enthält die Zieladresse, die zum Routen der geschützten Daten durch das Netzwerk benötigt wird. (Siehe Paketverarbeitung im Tunnelmodus.)

Mit ESP können Sie sowohl verschlüsseln als auch authentifizieren, nur verschlüsseln oder nur authentifizieren. Für die Verschlüsselung können Sie einen der folgenden Verschlüsselungsalgorithmen auswählen:

• Data Encryption Standard (DES): Ein kryptografischer Blockalgorithmus mit einem 56-Bit-Schlüssel.

• Triple DES (3DES): Eine leistungsstärkere Version von DES, in der der ursprüngliche DES-Algorithmus in drei Runden mit einer 168-Bit-Taste angewendet wird. DES ermöglicht erhebliche Leistungseinsparungen, wird aber für viele klassifizierte oder sensible Materialübertragungen als inakzeptabel angesehen.

• Advanced Encryption Standard (AES): Ein Verschlüsselungsstandard, der eine bessere Interoperabilität mit anderen Geräten bietet. Junos OS unterstützt AES mit 128-Bit-, 192-Bit- und 256-Bit-Schlüsseln.

Für die Authentifizierung können Sie entweder MD5- oder SHA-Algorithmen verwenden.

Obwohl es möglich ist, NULL für die Verschlüsselung auszuwählen, hat sich gezeigt, dass IPsec unter solchen Umständen anfällig für Angriffe sein kann. Deshalb empfehlen wir, dass Sie einen Verschlüsselungsalgorithmus für maximale Sicherheit wählen.