4. Conformance Requirements (Konformitätsanforderungen)

4. Conformance Requirements (Konformitätsanforderungen)

Um sicherzustellen, dass alle Implementierungen von IKEv2 (Internet Key Exchange Protocol Version 2) interoperieren können, gibt es neben den an anderer Stelle genannten Anforderungen auch „MUST support“-Anforderungen. Natürlich ist IKEv2 ein Sicherheitsprotokoll, und eine seiner Hauptaufgaben besteht darin, nur autorisierten Parteien die erfolgreiche Einrichtung von SAs (Security Associations, Sicherheitsassoziationen) zu ermöglichen. Eine konkrete Implementierung kann daher mit verschiedenen Einschränkungen bezüglich Algorithmen und vertrauenswürdiger Autoritäten konfiguriert sein, die eine universelle Interoperabilität verhindern.

IKEv2 ist so konzipiert, dass minimale Implementierungen möglich sind, die mit allen konformen Implementierungen interoperieren können. Die folgenden Funktionen können in einer minimalen Implementierung fehlen:

• Fähigkeit, SAs über ein NAT (Network Address Translation) auszuhandeln und die resultierende ESP-SA über UDP zu tunneln.

• Fähigkeit, eine temporäre IP-Adresse am entfernten Tunnelende anzufordern (und auf eine solche Anfrage zu antworten).

• Fähigkeit, EAP-basierte (Extensible Authentication Protocol) Authentifizierung zu unterstützen.

• Fähigkeit, Fenstergrößen größer als eins zu unterstützen.

• Fähigkeit, mehrere ESP- oder AH-SAs (Authentication Header) innerhalb einer einzigen IKE-SA einzurichten.

• Fähigkeit, SAs neu zu verhandeln (Rekeying).

Zur Gewährleistung der Interoperabilität MÜSSEN alle Implementierungen alle Nutzlasttypen parsen können (wenn auch nur, um sie zu überspringen) und Nutzlasttypen ignorieren, die nicht unterstützt werden, sofern im Nutzlastheader kein Critical-Bit gesetzt ist. Ist das Critical-Bit im Header einer nicht unterstützten Nutzlast gesetzt, MÜSSEN alle Implementierungen die Nachrichten ablehnen, die diese Nutzlasten enthalten.

Jede Implementierung MUSS in der Lage sein, vier Nachrichten umfassende IKE_SA_INIT- und IKE_AUTH-Austausche durchzuführen und zwei SAs (eine für IKE, eine für ESP oder AH) einzurichten. Implementierungen DÜRFEN nur initiierend oder nur antwortend sein, wenn das für ihre Plattform angemessen ist. Jede Implementierung MUSS auf einen INFORMATIONAL-Austausch antworten können, eine minimale Implementierung DARF jedoch auf jede Anfrage im INFORMATIONAL-Austausch mit einer leeren Antwort reagieren (im Kontext einer IKE-SA besteht eine „leere“ Nachricht aus einem IKE-Header gefolgt von einer verschlüsselten Nutzlast ohne innere Nutzlasten). Eine minimale Implementierung DARF den CREATE_CHILD_SA-Austausch nur insoweit unterstützen, dass Anfragen erkannt und mit einer Notify-Nutzlast vom Typ NO_ADDITIONAL_SAS abgelehnt werden. Eine minimale Implementierung muss CREATE_CHILD_SA- oder INFORMATIONAL-Austausche nicht initiieren können. Läuft eine SA ab (basierend auf lokal konfigurierten Werten für Lebensdauer oder übertragene Oktette), DARF eine Implementierung versuchen, sie per CREATE_CHILD_SA zu erneuern, oder sie DARF die alte SA löschen (schließen) und eine neue anlegen. Lehnt der Responder die CREATE_CHILD_SA-Anfrage mit einer NO_ADDITIONAL_SAS-Benachrichtigung ab, MUSS die Implementierung stattdessen die alte SA löschen und eine neue erstellen können.

Implementierungen müssen das Anfordern temporärer IP-Adressen oder das Beantworten solcher Anfragen nicht unterstützen. Unterstützt eine Implementierung das Stellen solcher Anfragen und verlangt ihre Richtlinie temporäre IP-Adressen, MUSS sie in der ersten Nachricht des IKE_AUTH-Austauschs eine CP-Konfigurationsnutzlast enthalten, die mindestens ein Feld vom Typ INTERNAL_IP4_ADDRESS oder INTERNAL_IP6_ADDRESS enthält. Alle anderen Felder sind optional. Unterstützt eine Implementierung das Beantworten solcher Anfragen, MUSS sie die CP-Nutzlast vom Typ CFG_REQUEST in der ersten Nachricht des IKE_AUTH-Austauschs parsen und ein Feld vom Typ INTERNAL_IP4_ADDRESS oder INTERNAL_IP6_ADDRESS erkennen. Unterstützt sie die Vergabe einer Adresse des passenden Typs, MUSS sie eine CP-Nutzlast vom Typ CFG_REPLY mit einer Adresse des angeforderten Typs zurückgeben. Der Responder kann weitere zugehörige Attribute aufnehmen.

Damit eine Implementierung als konform zu dieser Spezifikation bezeichnet werden kann, MUSS es möglich sein, sie so zu konfigurieren, dass sie Folgendes akzeptiert:

• Public-Key-Infrastruktur mit X.509-PKIX-Zertifikaten (Public Key Infrastructure using X.509), die RSA-Schlüssel mit 1024 oder 2048 Bit enthalten und von diesen signiert sind, wobei die übergebene ID eine von ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR oder ID_DER_ASN1_DN ist.

• Authentifizierung mit gemeinsamem Geheimnis, wobei die übergebene ID eine von ID_KEY_ID, ID_FQDN oder ID_RFC822_ADDR ist.

• Authentifizierung, bei der der Responder mit PKIX-Zertifikaten und der Initiator mit gemeinsamem Geheimnis authentifiziert wird.