Beide Seiten einigen sich beim Verbindungsaufbau über die für Verschlüsselung und Datensignierung zu verwendenden kryptographischen Algorithmen. Die Algorithmen sind für jede Phase separat einstellbar. Im Intra2net System können im Menü "" Profile mit Algorithmen konfiguriert werden.
Eine Verschlüsselungsmethode besteht dabei aus je einem Algorithmus für Verschlüsselung, für Hashing (Signatur) und einer Diffie Hellman Gruppe für die Vereinbarung von Sitzungsschlüsseln. Die meisten Algorithmen werden in verschiedenen Längen angeboten. Die Länge wird in Bit angegeben und der Algorithmus ist desto stärker, je mehr Bit verwendet werden. Allerdings steigt mit der Bitzahl auch der nötige Rechenaufwand.
Bei IKEv2 kommen, abhängig vom gewählten Algorithmus, noch die Pseudozufallsfunktion (PRF) und der Integritätsprüfwert (ICV) hinzu.
Einige Verschlüsselungsfunktionen können gleichzeitig verschlüsseln und signieren, dies wird Authenticated Encryption with Associated Data (AEAD) genannt. Dies bietet sowohl Schutz gegen bestimmte Klassen von Angriffen die auf den Unterschied zwischen Verschlüsselung und Signierung abzielen, als auch Vorteile bei Datendurchsatz und benötigter Rechenleistung. Diese Verfahren sind daher zu bevorzugen.
Normalerweise wird automatisch für Signatur und Pseudozufallsfunktion die selbe Funktion verwendet. Da bei AEAD kein separater Signaturalgorithmus verwendet wird, muss hier jetzt die Pseudozufallsfunktion (PRF) explizit ausgewählt werden.
Für beide Phasen, bzw. Arten von Security Associations (SA) bei IKEv2, wird nun eine Liste von möglichen Methoden hinterlegt. Diese Liste wird in der eingestellten Reihenfolge der Gegenstelle angeboten, die dann die oberste, von ihr auch unterstützte Methode verwendet.
Alle konfigurierten Verschlüsselungsmethoden / Algorithmenkombinationen werden beim Verbindungsaufbau zur Gegenseite übertragen. Es ist üblich, dass hier nicht beliebig viele verschiedene Algorithmenkombinationen akzeptiert werden. Die genaue Anzahl ist abhängig von der Implementation des IKE-Dienstes. Übliche Grenzen für die akzeptierte Anzahl von Algorithmenkombinationen pro Phase, bzw. pro Art von Security Association (SA) bei IKEv2, liegen zwischen 10 und 25.
Achten Sie daher darauf nicht zu viele verschiedene Verschlüsselungsmethoden / Algorithmenkombinationen in einem Verschlüsselungsprofil zu konfigurieren.
Bei IKE wird vor der Authentifizierung immer ein Sitzungsschlüssel mit dem Diffie-Hellman-Verfahren vereinbart. Die Ausnahme davon ist der Aggressive Mode von IKEv1, der deswegen als unsicher gilt und vom Intra2net System absichtlich nicht angeboten wird. Von diesem Sitzungsschlüssel können die Sitzungsschlüssel für die Übertragung der Nutzdaten direkt abgeleitet werden.
Perfect Forward Secrecy (PFS) bedeutet jetzt im Kontext von IPSec, dass die Sitzungsschlüssel für die Nutzdaten nicht direkt vom IKE-Sitzungsschlüssel abgeleitet werden, sondern neue, unabhängige Sitzungsschlüssel vereinbart werden. Sollte also aus irgendeinem Grund der Sitzungsschlüssel der IKE-Verbindung bekannt werden, bleibt durch PFS der Schutz der bisher übertragenen Nutzdaten gewahrt.
Da aber auch die IKE-Verbindung und ihre Sitzungsschlüssel normalerweise nach einigen Stunden automatisch erneuert werden, ist Perfect Forward Secrecy für IPSec zwar klar empfohlen, aber nicht absolut notwendig. Dies ist ein klarer Unterschied zu anderen Protokollen wie z.B. TLS, bei dem der Schutz der Nutzdaten ohne PFS direkt vom sehr langlebigen Schlüssel des Zertifikats abhängt und der Einsatz von PFS daher essentiell ist.
Ist auf dem Intra2net System eine PFS-Gruppe für Phase 2 vorgegeben, wird diese beim Verbindungsaufbau der Gegenseite vorgeschlagen. Es kann immer nur eine einzige PFS-Gruppe für Phase 2 vorgeschlagen werden und keine Liste an Kombinationen wie bei Verschlüsselung und Signaturalgorithmen.
Baut die Gegenseite die Verbindung auf und ist eine PFS-Gruppe konfiguriert, hängt es von der Option "Akzeptiere jede vorgeschlagene PFS Gruppe" ab, ob das Intra2net System auf die konfigurierte Gruppe besteht oder alle von der Gegenseite vorgeschlagenen akzeptiert.
Ist die PFS-Gruppe auf Keine gestellt, werden Verbindungen ohne PFS
aufgebaut. Baut die Gegenseite die Verbindung auf, werden Verbindungen mit beliebiger
PFS-Gruppe und ohne PFS akzeptiert.
PFS wird bei IKEv2 über die Option "Diffie Hellman Gruppe" beim Datentunnel (CHILD_SA) ausgewählt. Die Option wird der Gegenseite als Teil der Kombination aus Verschlüsselungs- und Signaturalgorithmus angeboten und muss von ihr akzeptiert werden. Es gibt hier keine besondere Behandlung dieses Parameters wie bei IKEv1 (siehe oben).
Der erste Aufbau einer CHILD_SA geschieht immer gleichzeitig mit der IKE_SA und der Authentifizierung und in diesem Moment ist die Aushandlung der Sitzungsschlüssel durch die direkt vorher erfolgte Schlüsselvereinbarung mit dem Diffie-Hellman-Verfahren geschützt. Daher wird beim ersten Aufbau einer CHILD_SA keine zusätzliche Schlüsselvereinbarung per Diffie-Hellman-Verfahren benötigt.
Bei den späteren Erneuerungen der CHILD_SAs ist dies anders. Wird hier Perfect-Forward-Secrecy gewünscht, ist eine weitere Diffie-Hellman-Schlüsselvereinbarung nötig. Sind sich beide Seiten an dieser Stelle in der Konfiguration ob, und mit welchem Algorithmus, uneinig, kann die Erneuerung der CHILD_SA fehlschlagen und in der Folge die Verbindung unterbrochen werden.