2.7. Aushandlung von Algorithmen

Jeder von einer Implementierung unterstützte kryptographische Algorithmus MUSS mit einem bestimmten SA-Attributtyp, einem Transformations-ID-Wert und allen erforderlichen Parametern (wie Schlüssellänge) angegeben sein. Diese sind in [IKEV2IANA] aufgeführt.

In einem einzelnen SA-Vorschlag KANN eine Implementierung mehrere Sätze von Transformationen auflisten, die mit einem Vorschlag kompatibel sind. Die Mitglieder jedes Satzes MÜSSEN alle kompatibel sein. Wenn die Transformations-ID "NONE" (Wert 0) aufgelistet ist, MUSS diese Transformations-ID die einzige für diesen Typ aufgelistete Transformation sein. NONE ist nur für Integritätsalgorithmen erlaubt. Ein NONE-Integritätsalgorithmus bedeutet, dass kein Integritätsschutz geboten wird, es sei denn, ein kombiniertes Verschlüsselungsverfahren wird verwendet (siehe Abschnitt 3.3.2). Wenn ein kombinierter Verschlüsselungsalgorithmus ausgewählt wird, SOLLTE für den Verschlüsselungsalgorithmus kein separater Integritätsalgorithmus angegeben werden, und MUST MUSS NONE sein (siehe Abschnitt 3.3.2). In allen anderen Fällen MUSS NONE abgelehnt werden.

Der Initiator MUSS mindestens einen von seiner Implementierung unterstützten Vorschlag machen, und der Responder MUSS den ersten von seiner Implementierung unterstützten Vorschlag akzeptieren. Bei mehreren kompatiblen Vorschlägen ist das Verhalten des Responders implementierungsspezifisch. Der Initiator DARF NUR Vorschläge einschließen, die von seiner Implementierung unterstützt werden. Der Responder KANN einen gültigen Vorschlag ablehnen, wenn er in einem früheren IKE-Austausch bereits einen bevorzugten Vorschlag vom Peer erhalten und gemacht hat.

Um jedes Protokoll (IKE oder AH oder ESP) auszuhandeln, MUSS sich im SA-Payload mindestens ein Vorschlag befinden, und jeder Vorschlag MUSS mindestens eine Transformation jedes Typs enthalten: höchstens eine Transformation jeden Typs (Verschlüsselung, Integrität, PRF und DH), es sei denn, mehrere Transformationen können nicht separat ausgehandelt werden (z. B. ein kombinierter Verschlüsselungsalgorithmus, der Integritätsschutz einschließt, aber nicht als separate Transformation). Das Verschlüsselungsset selbst kann kombiniert sein, aber beachten Sie, dass kombinierte Algorithmen im SA-Payload als eine einzelne Transformation dargestellt werden.

2.7.1. Auswahl der Verschlüsselungssuits

Jede Implementierung MUSS die folgenden Verschlüsselungssuits implementieren:

Verschlüsselung: ENCR_AES_CBC sowie der AEAD-Verschlüsselungsalgorithmus ENCR_AES_GCM_16 (siehe Abschnitt 3.3.2). Implementierungen KÖNNEN ENCR_AES_CTR als alternative AES-Transformation implementieren. Implementierungen KÖNNEN ENCR_3DES, ENCR_DES, ENCR_CAST und ENCR_BLOWFISH implementieren, diese sind jedoch veraltet und werden für neue Implementierungen nicht empfohlen (SHOULD NOT).
Pseudozufallsfunktion: PRF_HMAC_SHA1. Implementierungen MÜSSEN PRF_HMAC_SHA1 implementieren und KÖNNEN PRF_AES128_XCBC sowie PRF_HMAC_SHA2_256, PRF_HMAC_SHA2_384 oder PRF_HMAC_SHA2_512 implementieren.
Integrität: AUTH_HMAC_SHA1_96. Implementierungen MÜSSEN AUTH_HMAC_SHA1_96 implementieren und KÖNNEN AUTH_AES_XCBC_96, AUTH_HMAC_SHA2_256_128, AUTH_HMAC_SHA2_384_192 oder AUTH_HMAC_SHA2_512_256 implementieren.
Endliche DH-Gruppen: Implementierungen MÜSSEN die 1024-Bit-MODP-Gruppe 2 und die EC-Gruppe 19 implementieren. Implementierungen KÖNNEN alternativ die 2048-Bit-MODP-Gruppe 14 (sowie die EC-Gruppen 20, 21, 23, 24 oder 25) implementieren. Die Interoperabilität zwischen EC-Gruppen und Gruppe 2 ist noch nicht etabliert, aber der Vorteil der Standardisierung besteht darin, dass Bereitstellungen sich auf eine bestimmte Gruppe standardisieren können, falls neuere Implementierungen nur EC-Gruppen unterstützen.
Implementierungen KÖNNEN andere Diffie-Hellman-Gruppen implementieren, dies ist jedoch nicht ERFORDERLICH.

Es scheint, dass dieses Dokument die Implementierung bestimmter Algorithmen nicht verlangen sollte, da Fortschritte in der Kryptoanalyse sie veralten lassen könnten; wenn jedoch alle Implementierungen unterschiedliche Mengen optionaler Algorithmen wählen würden, wäre Interoperabilität unmöglich. Daher definiert dieses Dokument eine minimale Menge zwingender Algorithmen und verlangt, dass neue Algorithmen mit diesen Algorithmen ausgehandelt werden. Daher SOLLTEN alle für eine Implementierung benötigten Algorithmen zwingend und standardisiert sein (wie oben) oder eine der oben aufgeführten zwingenden Algorithmen implementieren.

Implementierungen SOLLTEN X.509-v3-Zertifikate für die Identifizierung sowie RSA und irreversibles ECDSA (wie in [PKI] und [EAIKEv2] beschrieben) für die Signatur (im AUTH-Payload) unterstützen. Um EAP zu unterstützen, MÜSSEN Implementierungen die EAP-Authentifizierung unterstützen. Implementierungen, die EAP unterstützen, SOLLTEN die EAP-Methode EAP-MSCHAPv2 unterstützen und KÖNNEN andere Methoden unterstützen. Die Unterstützung der Authentifizierung mit vorab geteiltem Schlüssel wird dringend EMPFOHLEN.

2.7.2. Erneute Aushandlung

In einer IKE-SA SOLLTE der Verschlüsselungssuit der ausgehandelten Verschlüsselungsalgorithmen während der Lebensdauer der SA nicht geändert werden (SHOULD NOT), es sei denn, andere Vereinbarungen werden getroffen (z. B. über einen "flüchtigen" CREATE_CHILD_SA-Austausch, siehe Abschnitt 2.18). Eine erneute Aushandlung KANN initiiert werden, um eine demnächst ablaufende SA zu ersetzen, neue (zertifikatsbasierte) Schlüssel oder Identitäten für eine bestehende IKE-SA auszuhandeln oder die Attribute der IKE-SA zu ändern (z. B. Wechsel von vorab geteiltem Schlüssel zur Zertifikatsauthentifizierung). Während der erneuten Aushandlung wird fast der gesamte Nachrichtenfluss wiederholt, allerdings innerhalb des geschützten Teils der bestehenden IKE-SA statt im Klartext.

Da die erneute Aushandlung den CREATE_CHILD_SA-Austausch verwendet, hat sie den Effekt, eine neue Child-SA für die bestehende IKE-SA zu erzeugen. Der Initiator KANN im CREATE_CHILD_SA-Austausch keinen SA-Payload (einschließlich Protokoll-ID) angeben, um anzuzeigen, dass er die IKE-SA selbst neu aushandeln möchte, anstatt eine neue Child-SA zu erzeugen. In diesem Fall DARF der CREATE_CHILD_SA-Austausch, wenn er zur erneuten Aushandlung der IKE-SA verwendet wird, NICHT gleichzeitig zur Erzeugung einer Child-SA verwendet werden. Dieser Austauschtyp wird auch als "Typ-1"-Neuverhandlung bezeichnet.

Wenn der Initiator einen SA-Payload in den CREATE_CHILD_SA-Austausch einschließt, MUSS dieser SA-Payload verwendet werden, um eine Child-SA (oder zusätzliche Child-SAs) zu erzeugen, während die IKE-SA neu ausgehandelt wird, und der Responder MUSS ihn akzeptieren. Dieser Austauschtyp wird auch als "Typ-2"-Neuverhandlung bezeichnet. Die Unterstützung von Typ-2-Neuverhandlung ist nicht ERFORDERLICH.

2.7.3. Unterstützte Authentifizierungsmethoden

Implementierungen MÜSSEN die folgenden Authentifizierungsmethoden unterstützen:

Auf digitaler Signatur basierend (siehe Abschnitt 3.8), unter Verwendung der RSA- oder irreversiblen ECDSA-Algorithmen, wie in [PKI] und [EAIKEv2] beschrieben.
Vorab geteilter Schlüssel (siehe Abschnitte 2.15 und 3.8).
Extensible Authentication Protocol (EAP), wie in [EAP] beschrieben.

Implementierungen KÖNNEN andere Authentifizierungsmethoden unterstützen, dies ist jedoch nicht ERFORDERLICH.