Zum Hauptinhalt springen

4. Konformitätsanforderungen

Um sicherzustellen, dass alle Implementierungen von IKEv2 interoperieren können, gibt es zusätzlich zu den andernorts aufgeführten Anforderungen auch „MUST support"-Anforderungen. IKEv2 ist selbstverständlich ein Sicherheitsprotokoll, und eine seiner Hauptfunktionen ist es, nur autorisierten Parteien den erfolgreichen Abschluss der SA-Einrichtung zu gestatten. Daher kann eine bestimmte Implementierung mit einer Reihe von Beschränkungen bezüglich Algorithmen und vertrauenswürdigen Stellen konfiguriert sein, die eine universelle Interoperabilität verhindern.

IKEv2 ist so konzipiert, dass minimale Implementierungen zulässig sind, die mit allen konformen Implementierungen interoperieren können. Folgende Funktionen können in einer Minimalimplementierung weggelassen werden:

  • Die Fähigkeit, SAs durch ein NAT auszuhandeln und die resultierende ESP-SA über UDP zu tunneln.
  • Die Fähigkeit, eine temporäre IP-Adresse am fernen Ende eines Tunnels anzufordern (und auf eine Anforderung zu antworten).
  • Die Fähigkeit, EAP-basierte Authentifizierung zu unterstützen.
  • Die Fähigkeit, Fenstergrößen größer als eins zu unterstützen.
  • Die Fähigkeit, mehrere ESP- oder AH-SAs innerhalb einer einzigen IKE SA zu etablieren.
  • Die Fähigkeit, SAs neu zu schlüsseln (Rekeying).

Um die Interoperabilität zu gewährleisten, MÜSSEN alle Implementierungen in der Lage sein, alle Payload-Typen zu parsen (selbst wenn es nur darum geht, sie zu überspringen), und Payload-Typen, die sie nicht unterstützen, zu ignorieren, es sei denn, das Critical-Bit ist im Payload-Header gesetzt. Ist das Critical-Bit in einem nicht unterstützten Payload-Header gesetzt, MÜSSEN alle Implementierungen die Nachrichten ablehnen, die diese Payloads enthalten.

Jede Implementierung MUSS in der Lage sein, den vier Nachrichten umfassenden IKE_SA_INIT- und IKE_AUTH-Austausch durchzuführen und zwei SAs (eine für IKE, eine für ESP oder AH) zu etablieren. Implementierungen DÜRFEN, sofern für ihre Plattform geeignet, ausschließlich initiierend oder ausschließlich antwortend sein. Jede Implementierung MUSS in der Lage sein, auf einen INFORMATIONAL-Austausch zu antworten, aber eine Minimalimplementierung KANN auf jede Anfrage im INFORMATIONAL-Austausch mit einer leeren Antwort reagieren (beachten Sie, dass im Kontext einer IKE SA eine „leere" Nachricht aus einem IKE-Header besteht, gefolgt von einem Encrypted-Payload ohne enthaltene Payloads). Eine Minimalimplementierung KANN den CREATE_CHILD_SA-Austausch nur insoweit unterstützen, als sie Anfragen erkennt und sie mit einem Notify-Payload vom Typ NO_ADDITIONAL_SAS ablehnt. Eine Minimalimplementierung muss nicht in der Lage sein, CREATE_CHILD_SA- oder INFORMATIONAL-Austausche zu initiieren. Wenn eine SA abläuft (basierend auf lokal konfigurierten Werten für Lebensdauer oder übertragene Oktette), KANN die Implementierung entweder versuchen, sie mit einem CREATE_CHILD_SA-Austausch zu erneuern, oder sie KANN die alte SA löschen (schließen) und eine neue erstellen. Lehnt der Responder die CREATE_CHILD_SA-Anfrage mit einer NO_ADDITIONAL_SAS-Benachrichtigung ab, MUSS die Implementierung in der Lage sein, stattdessen die alte SA zu löschen und eine neue zu erstellen.

Implementierungen wird nicht abverlangt, das Anfordern temporärer IP-Adressen oder das Antworten auf solche Anfragen zu unterstützen. Wenn eine Implementierung das Ausstellen solcher Anfragen unterstützt und ihre Richtlinie die Verwendung temporärer IP-Adressen verlangt, MUSS sie in der ersten Nachricht des IKE_AUTH-Austauschs einen CP-Payload enthalten, der mindestens ein Feld vom Typ INTERNAL_IP4_ADDRESS oder INTERNAL_IP6_ADDRESS enthält. Alle anderen Felder sind optional. Wenn eine Implementierung das Antworten auf solche Anfragen unterstützt, MUSS sie den CP-Payload 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 entsprechenden Typs, MUSS sie einen CP-Payload vom Typ CFG_REPLY zurückgeben, der eine Adresse des angeforderten Typs enthält. Der Responder KANN beliebige andere zugehörige Attribute einschließen.

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

  • Public-Key-Infrastruktur unter Verwendung von X.509-(PKIX-)Zertifikaten, die von RSA-Schlüsseln der Größe 1024 oder 2048 Bit enthalten und signiert sind, wobei die übergebene ID eine der IDs ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR oder ID_DER_ASN1_DN ist.
  • Shared-Key-Authentifizierung, wobei die übergebene ID eine der IDs ID_KEY_ID, ID_FQDN oder ID_RFC822_ADDR ist.
  • Authentifizierung, bei der der Responder mittels PKIX-Zertifikaten und der Initiator mittels Shared-Key-Authentifizierung authentifiziert wird.