1. Introduction
1. Introduction
IP Security (IPsec) fournit la confidentialité, l'intégrité des données, le contrôle d'accès et l'authentification de la source des données aux datagrammes IP. Ces services sont fournis en maintenant un état partagé entre la source et la destination d'un datagramme IP. Cet état définit, entre autres, les services spécifiques fournis au datagramme, les algorithmes cryptographiques qui seront utilisés pour fournir les services, et les clés utilisées comme entrée des algorithmes cryptographiques.
L'établissement de cet état partagé de manière manuelle ne passe pas à l'échelle. Par conséquent, un protocole pour établir cet état dynamiquement est nécessaire. Ce document décrit un tel protocole : l'Internet Key Exchange (IKE, échange de clés Internet). La version 1 d'IKE a été définie dans les RFC 2407 [DOI], 2408 [ISAKMP] et 2409 [IKEV1]. IKEv2 a remplacé tous ces RFC. IKEv2 a été défini dans [IKEV2] (RFC 4306) et clarifié dans [Clarif] (RFC 4718). Ce document remplace et met à jour les RFC 4306 et 4718. IKEv2 était une modification du protocole IKE qui n'était pas rétrocompatible. En revanche, le document actuel non seulement fournit une clarification d'IKEv2, mais apporte des modifications minimales au protocole IKE. Une liste des différences significatives entre la RFC 4306 et ce document est donnée dans la section 1.7.
IKE effectue une authentification mutuelle entre deux parties et établit une association de sécurité IKE (IKE security association, SA) qui inclut des informations secrètes partagées pouvant être utilisées pour établir efficacement des SA pour Encapsulating Security Payload (ESP, charge utile de sécurité encapsulante) [ESP] ou Authentication Header (AH, en-tête d'authentification) [AH] et un ensemble d'algorithmes cryptographiques à utiliser par les SA pour protéger le trafic qu'elles transportent. Dans ce document, le terme "suite" ou "suite cryptographique" fait référence à un ensemble complet d'algorithmes utilisés pour protéger une SA. Un initiateur propose une ou plusieurs suites en listant les algorithmes supportés qui peuvent être combinés en suites de manière mixte. IKE peut également négocier l'utilisation de la compression IP (IPComp) [IP-COMP] en liaison avec une SA ESP ou AH. Les SA pour ESP ou AH qui sont configurées via cette SA IKE sont appelées "Child SAs (SA enfants)".
Toutes les communications IKE consistent en paires de messages : une requête et une réponse. La paire est appelée un "exchange (échange)", et est parfois appelée "request/response pair (paire requête/réponse)". Le premier échange de messages établissant une SA IKE est appelé échanges IKE_SA_INIT et IKE_AUTH; les échanges IKE suivants sont appelés échanges CREATE_CHILD_SA ou INFORMATIONAL. Dans le cas courant, il y a un seul échange IKE_SA_INIT et un seul échange IKE_AUTH (un total de quatre messages) pour établir la SA IKE et la première SA enfant. Dans des cas exceptionnels, il peut y avoir plus d'un de chacun de ces échanges. Dans tous les cas, tous les échanges IKE_SA_INIT doivent se terminer avant tout autre type d'échange, puis tous les échanges IKE_AUTH doivent se terminer, et après cela, un nombre quelconque d'échanges CREATE_CHILD_SA et INFORMATIONAL peut se produire dans n'importe quel ordre. Dans certains scénarios, une seule SA enfant est nécessaire entre les points terminaux IPsec, et il n'y aurait donc pas d'échanges supplémentaires. Les échanges suivants peuvent être utilisés pour établir des SA enfants supplémentaires entre la même paire de points terminaux authentifiés et pour effectuer des fonctions de maintenance.
Un flux de messages IKE consiste toujours en une requête suivie d'une réponse. Il est de la responsabilité du demandeur d'assurer la fiabilité. Si la réponse n'est pas reçue dans un intervalle de temporisation, le demandeur doit retransmettre la requête (ou abandonner la connexion).
Le premier échange d'une session IKE, IKE_SA_INIT, négocie les paramètres de sécurité pour la SA IKE, envoie des nonces et envoie des valeurs Diffie-Hellman.
Le deuxième échange, IKE_AUTH, transmet les identités, prouve la connaissance des secrets correspondant aux deux identités, et configure une SA pour la première (et souvent unique) SA enfant AH ou ESP (sauf s'il y a un échec de configuration de la SA enfant AH ou ESP, auquel cas la SA IKE est toujours établie sans la SA enfant).
Les types d'échanges suivants sont CREATE_CHILD_SA (qui crée une SA enfant) et INFORMATIONAL (qui supprime une SA, signale des conditions d'erreur ou effectue d'autres tâches de maintenance). Chaque requête nécessite une réponse. Une requête INFORMATIONAL sans charges utiles (autre que la charge utile chiffrée vide requise par la syntaxe) est couramment utilisée comme vérification de vivacité. Ces échanges suivants ne peuvent pas être utilisés tant que les échanges initiaux ne sont pas terminés.
Dans la description qui suit, nous supposons qu'aucune erreur ne se produit. Les modifications du flux lorsque des erreurs se produisent sont décrites dans la section 2.21.