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 le puits 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 ces services, et les clés utilisées comme entrée des algorithmes cryptographiques.

Établir cet état partagé manuellement ne passe pas bien à l'échelle. Il est donc nécessaire d'un protocole pour l'établir dynamiquement. Ce document décrit un tel protocole, l'Internet Key Exchange (IKE). La version 1 d'IKE était 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). [RFC5996] a remplacé et mis à jour les RFC 4306 et 4718. Ce document remplace le RFC 5996. IKEv2 tel qu'énoncé dans le RFC 4306 était un changement du protocole IKE non rétrocompatible. Le RFC 5996 a révisé le RFC 4306 pour clarifier IKEv2, avec des changements minimaux au protocole IKEv2. Ce document remplace le RFC 5996, le révisant légèrement pour le rendre apte à devenir une norme Internet. Une liste des différences significatives entre les RFC 4306 et 5996 est donnée à la section 1.7, et les différences entre le RFC 5996 et ce document à la section 1.8.

IKE effectue une authentification mutuelle entre deux parties et établit une IKE Security Association (SA) incluant des informations secrètes partagées utilisables pour établir efficacement des SA pour Encapsulating Security Payload (ESP) [ESP] ou Authentication Header (AH) [AH], ainsi qu'un ensemble d'algorithmes cryptographiques pour protéger le trafic qu'elles portent. Dans ce document, le terme "suite" ou "cryptographic suite" désigne un ensemble complet d'algorithmes utilisés pour protéger une SA. Un initiator propose une ou plusieurs suites en listant des algorithmes pris en charge pouvant être combinés en suites de façon modulaire. IKE peut aussi négocier l'utilisation de IP Compression (IPComp) [IP-COMP] en lien avec une SA ESP ou AH. Les SA pour ESP ou AH établies via cette IKE SA sont appelées "Child SAs".

Toutes les communications IKE consistent en paires de messages : une requête et une réponse. La paire est appelée un "exchange", parfois "request/response pair". Les deux premiers échanges de messages établissant une IKE SA sont l'échange IKE_SA_INIT et l'échange IKE_AUTH ; les échanges IKE ultérieurs sont des échanges CREATE_CHILD_SA ou INFORMATIONAL. Dans le cas courant, un seul échange IKE_SA_INIT et un seul IKE_AUTH (quatre messages au total) suffisent pour établir l'IKE SA et la première Child SA. Dans des cas exceptionnels, il peut y en avoir plusieurs de chaque. 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, après quoi un nombre quelconque d'échanges CREATE_CHILD_SA et INFORMATIONAL peut survenir dans n'importe quel ordre. Dans certains scénarios, une seule Child SA suffit entre les points de terminaison IPsec, donc il n'y aurait pas d'échanges supplémentaires. Des échanges ultérieurs PEUVENT servir à établir des Child SA supplémentaires entre la même paire d'extrémités authentifiées et à effectuer des fonctions de maintenance.

Un flux de messages IKE consiste toujours en une requête suivie d'une réponse. Il incombe au demandeur d'assurer la fiabilité. Si la réponse n'est pas reçue dans un délai d'expiration, 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 l'IKE SA, envoie des nonces et des valeurs Diffie-Hellman.

Le second échange, IKE_AUTH, transmet les identités, prouve la connaissance des secrets correspondant aux deux identités, et met en place une SA pour la première (et souvent unique) Child SA AH ou ESP (sauf en cas d'échec de mise en place de la Child SA AH ou ESP, auquel cas l'IKE SA est quand même établie sans Child SA).

Les types d'échanges ultérieurs sont CREATE_CHILD_SA (qui crée une Child SA) et INFORMATIONAL (qui supprime une SA, signale des erreurs ou effectue d'autres opérations de maintenance). Chaque requête exige une réponse. Une requête INFORMATIONAL sans charges utiles (autre que la charge Encrypted vide exigée par la syntaxe) sert couramment de vérification de vivacité. Ces échanges ultérieurs ne peuvent être utilisés qu'après achèvement des échanges initiaux.

Dans la description qui suit, nous supposons qu'aucune erreur ne survient. Les modifications du flux en cas d'erreur sont décrites à la section 2.21.

1. Introduction​

Contents​

1. Introduction

Contents