4. Conformance Requirements

4. Conformance Requirements

Afin de garantir l'interopérabilité entre toutes les implémentations d'IKEv2 (Internet Key Exchange Protocol Version 2), des exigences « MUST support » s'ajoutent à celles énoncées ailleurs. Bien entendu, IKEv2 est un protocole de sécurité dont l'une des fonctions majeures est de n'autoriser que les parties autorisées à établir des SA (Security Associations, associations de sécurité). Une implémentation donnée peut donc être configurée avec diverses restrictions concernant les algorithmes et les autorités de confiance, ce qui empêchera une interopérabilité universelle.

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

• Capacité à négocier des SA à travers un NAT (Network Address Translation) et à encapsuler la SA ESP résultante sur UDP.

• Capacité à demander (et à répondre à une demande d') une adresse IP temporaire à l'extrémité distante d'un tunnel.

• Capacité à prendre en charge l'authentification basée sur EAP (Extensible Authentication Protocol).

• Capacité à prendre en charge des fenêtres de taille supérieure à un.

• Capacité à établir plusieurs SA ESP ou AH (Authentication Header) au sein d'une seule SA IKE.

• Capacité à renégocier les clés des SA.

Pour garantir l'interopérabilité, toutes les implémentations DOIVENT être capables d'analyser tous les types de charge utile (ne serait-ce que pour les ignorer) et d'ignorer les types non pris en charge, sauf si le bit critique est positionné dans l'en-tête de charge utile. Si le bit critique est positionné pour un en-tête non pris en charge, toutes les implémentations DOIVENT rejeter les messages contenant ces charges utiles.

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 n'être qu'initiatrices ou que répondeuses si cela convient à leur plate-forme. Chaque implémentation DOIT être capable de répondre à un échange INFORMATIONAL, mais une implémentation minimale PEUT répondre à toute demande dans l'échange INFORMATIONAL par une réponse vide (dans le contexte d'une SA IKE, un message « vide » consiste en un en-tête IKE suivi d'une charge utile chiffrée sans charges utiles internes). Une implémentation minimale PEUT ne prendre en charge l'échange CREATE_CHILD_SA que pour reconnaître les demandes et les rejeter avec une charge utile Notify de type NO_ADDITIONAL_SAS. Une implémentation minimale n'a pas besoin de pouvoir initier des échanges CREATE_CHILD_SA ou INFORMATIONAL. Lorsqu'une SA expire (selon des valeurs locales de durée de vie ou d'octets transmis), une implémentation PEUT tenter de la renouveler par un échange CREATE_CHILD_SA ou PEUT supprimer (fermer) l'ancienne SA en en créer une nouvelle. Si le répondeur rejette la demande 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 ni d'y répondre. Si une implémentation prend en charge l'émission de telles demandes et que sa politique exige des adresses IP temporaires, elle DOIT inclure une charge utile CP (Configuration) 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 facultatifs. Si une implémentation prend en charge la réponse à de telles demandes, elle DOIT analyser la charge utile 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 l'attribution d'une adresse du type approprié, elle DOIT renvoyer une charge utile CP de type CFG_REPLY contenant une adresse du type demandé. Le répondeur peut inclure tout autre attribut connexe.

Pour qu'une implémentation soit dite conforme à la présente spécification, il DOIT être possible de la configurer pour accepter les éléments suivants :

• Infrastructure à clés publiques X.509 PKIX (Public Key Infrastructure using X.509) avec certificats contenant des clés RSA de 1 024 ou 2 048 bits et signés par celles-ci, l'identifiant transmis étant l'un de ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR ou ID_DER_ASN1_DN.

• Authentification par clé partagée avec un identifiant transmis parmi ID_KEY_ID, ID_FQDN ou ID_RFC822_ADDR.

• Authentification où le répondeur est authentifié par certificats PKIX et l'initiateur par clé partagée.