4. Exigences de conformité

Afin de garantir que toutes les implémentations d'IKEv2 puissent interopérer, il existe des exigences « MUST support » en plus de celles énumérées ailleurs. Bien sûr, IKEv2 est un protocole de sécurité, et l'une de ses fonctions principales est de n'autoriser que les parties autorisées à compléter avec succès l'établissement des SA. Ainsi, une implémentation particulière peut être configurée avec un certain nombre de restrictions concernant les algorithmes et les autorités de confiance qui empêcheront une interopérabilité universelle.

IKEv2 est conçu pour permettre des implémentations minimales capables d'interopérer avec toutes les implémentations conformes. Voici les fonctionnalités qui peuvent être omises dans une implémentation minimale :

La capacité de négocier des SA à travers un NAT et de tunneliser la SA ESP résultante sur UDP.
La capacité de demander (et de répondre à une demande de) une adresse IP temporaire à l'extrémité distante d'un tunnel.
La capacité de prendre en charge l'authentification basée sur EAP.
La capacité de prendre en charge des tailles de fenêtre supérieures à un.
La capacité d'établir plusieurs SA ESP ou AH au sein d'une seule IKE SA.
La capacité de rekeyer les SA.

Pour garantir l'interopérabilité, toutes les implémentations DOIVENT être capables d'analyser tous les types de payload (même simplement pour les ignorer) et d'ignorer les types de payload qu'elles ne prennent pas en charge, sauf si le bit critique est défini dans l'en-tête du payload. Si le bit critique est défini dans un en-tête de payload non pris en charge, toutes les implémentations DOIVENT rejeter les messages contenant ces payloads.

Chaque implémentation DOIT être capable d'effectuer les échanges IKE_SA_INIT et IKE_AUTH en quatre messages, établissant deux SA (une pour IKE, une pour ESP ou AH). Les implémentations PEUVENT être uniquement initiatrices ou uniquement répondantes si cela convient à leur plateforme. Chaque implémentation DOIT être capable de répondre à un échange INFORMATIONAL, mais une implémentation minimale PEUT répondre à toute requête de l'échange INFORMATIONAL par une réponse vide (notez que, dans le contexte d'une IKE SA, un message « vide » consiste en un en-tête IKE suivi d'un payload chiffré ne contenant aucun payload). Une implémentation minimale PEUT ne prendre en charge l'échange CREATE_CHILD_SA qu'au point de reconnaître les requêtes et de les rejeter avec un payload Notify de type NO_ADDITIONAL_SAS. Une implémentation minimale n'a pas besoin d'être capable d'initier les échanges CREATE_CHILD_SA ou INFORMATIONAL. Lorsqu'une SA expire (sur la base des valeurs configurées localement de durée de vie ou d'octets transmis), l'implémentation PEUT soit tenter de la renouveler avec un échange CREATE_CHILD_SA, soit supprimer (fermer) l'ancienne SA et en créer une nouvelle. Si le répondeur rejette la requête CREATE_CHILD_SA avec une notification NO_ADDITIONAL_SAS, l'implémentation DOIT être capable de supprimer l'ancienne SA et d'en créer une nouvelle à la place.

Les implémentations ne sont pas tenues de prendre en charge la demande d'adresses IP temporaires ou la réponse à de telles demandes. Si une implémentation prend en charge l'émission de telles demandes et que sa politique exige l'utilisation d'adresses IP temporaires, elle DOIT inclure un payload CP dans le premier message de l'échange IKE_AUTH contenant au moins un champ de type INTERNAL_IP4_ADDRESS ou INTERNAL_IP6_ADDRESS. Tous les autres champs sont optionnels. Si une implémentation prend en charge la réponse à de telles demandes, elle DOIT analyser le payload CP de type CFG_REQUEST dans le premier message de l'échange IKE_AUTH et reconnaître un champ de type INTERNAL_IP4_ADDRESS ou INTERNAL_IP6_ADDRESS. Si elle prend en charge la location d'une adresse du type approprié, elle DOIT renvoyer un payload CP de type CFG_REPLY contenant une adresse du type demandé. Le répondeur peut inclure tout autre attribut lié.

Pour qu'une implémentation soit qualifiée de conforme à cette spécification, il DOIT être possible de la configurer pour accepter ce qui suit :

L'infrastructure à clé publique utilisant des certificats X.509 (PKIX) contenant et signés par des clés RSA de taille 1024 ou 2048 bits, où l'ID transmis est l'un des ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR ou ID_DER_ASN1_DN.
L'authentification par clé partagée où l'ID transmis est l'un des ID_KEY_ID, ID_FQDN ou ID_RFC822_ADDR.
L'authentification où le répondeur est authentifié à l'aide de certificats PKIX et l'initiateur est authentifié à l'aide d'une authentification par clé partagée.