View source for Echanges ISAKMP/IKEv1

From Livre IPv6

You do not have permission to edit this page, for the following reason:
The action you have requested is limited to users in one of the groups: Users, Administrators.
You can view and copy the source of this page:
Enfin, ISAKMP comporte deux phases qui permettent une séparation nette de la négociation des associations de sécurité pour IPsec et de la protection du trafic propre à ISAKMP :

* Durant la phase 1, un ensemble d'attributs relatifs à la sécurité est négocié, les identités des entités sont authentifiées et des clés sont générées. Ces éléments constituent une première association de sécurité, dite SA ISAKMP. Contrairement aux associations de sécurité IPsec, le SA ISAKMP est bidirectionnel. Il servira à protéger l'ensemble des échanges ISAKMP futurs.
* La phase 2 permet de négocier les paramètres de sécurité relatifs à une association de sécurité à établir pour le compte d'un protocole de sécurité donné (par exemple AH ou ESP). Les échanges de cette phase sont protégés en confidentialité et intégrité/authentification grâce au SA ISAKMP. Ce dernier peut bien sûr être utilisé pour négocier plusieurs associations de sécurité destinées à d'autres protocoles de sécurité.

ISAKMP définit des types d'échanges (exchange types). Un type d'échange est une spécification de l'ensemble des messages constituant un type d'échange donné (nombre, contenu). Chaque type d'échange est conçu pour fournir un certain nombre de services de sécurité spécifiques, comme l'anonymat, la propriété de ''Perfect Forward Secrecy'' (PFS) et l'authentification mutuelle.

IKE comprend quatre modes :

* le mode principal (''Main Mode''),
* le mode agressif (''Aggressive Mode''),
* le mode rapide (''Quick Mode'') et
* le mode nouveau groupe (''New Group Mode'').

Comme le montre la figure Phases d'IKEv1, ''Main Mode'' ou ''Aggressive Mode'' sont utilisés pour la phase 1 de la négociation ISAKMP ; ''Quick Mode'' est un échange de la phase 2 avec deux variantes suivant que la propriété de PFS est rendue ou non.

[[image:CS135.gif]]

''New Group Mode'' est un peu à part : ce n'est ni un échange de la phase 1, ni un échange de la phase 2, mais il ne peut avoir lieu qu'après l'établissement d'une SA ISAKMP. Il sert à convenir d'un nouveau groupe pour de futurs échanges Diffie-Hellman.

===Phase 1 de IKEv1===

Durant la phase 1, IKE négocie les attributs -- algorithme de chiffrement, fonction de hachage, méthode d'authentification et groupe mathématique pour les calculs relatifs à Diffie-Hellman -- et produit trois clés qui serviront pour chiffrer, authentifier et dériver d'autres clés. Ces attributs et ces clés permettent de protéger les messages de la phase 2 en authentification et confidentialité. L'authentification des messages est assurée par l'ajout d'un bloc HASH après l'en-tête ISAKMP, et la confidentialité est assurée par le chiffrement de l'ensemble des blocs du message. L'une des trois clés sert à produite deux autres clés utiles à la protection des échanges IPsec en authentification/intégrité et confidentialité.

''Main Mode'' se compose de six messages comme le montre la figure Echanges - Phase 1 d'IKEv1 (''main mode'') :

[[image:CS136.gif]]

* les deux premiers messages servent à négocier l'association de sécurité ISAKMP, ou en d'autres termes les paramètres propres à IKE : algorithme de chiffrement, fonction de hachage, méthode d'authentification des tiers et groupe pour Diffie- Hellman. Les blocs ISAKMP transportés sont de type ''Security Association'', ''Proposal'' et ''Transform''. L'initiateur propose plusieurs combinaisons d'algorithmes, mécanismes, et méthodes, et le partenaire IKE en choisit un. Pour information, la notation HDR sur les figures Echanges - Phase 1 d'IKEv1 (''main mode'') et Echanges - Phase 2 d'IKEv1 (''quick mode'') signifie "header" pour l'en-tête des messages IKE comprenant entre autres l'index SPI, le numéro de version.
* Pour s'authentifier, les équipements IPsec utilisent soit un secret partagé, soit des clés publique/privée, soit un certificat.
* les deux suivants permettent l'établissement d'un secret partagé via l'utilisation d'un échange de valeurs publiques Diffie-Hellman.
* Le secret partagé sert à dériver des clés de session, deux d'entre elles étant utilisées pour protéger la suite des échanges avec les algorithmes de chiffrement et de hachage négociés précédemment. Les blocs ISAKMP sont de type ''Key Exchange'', ''Nonce'' et optionnellement ''Certificate Request''.
* les deux derniers messages permettent aux tiers d'échanger leurs identités et servent à l'authentification de l'ensemble des données échangées (et donc des tiers en présence). Les blocs ISAKMP sont de type ID, SIG et optionnellement CERT. Le bloc SIG peut être formé selon trois méthodes d'authentification basées soit sur des clés partagées, soit des certificats X.509, soit un chiffrement avec des clés publiques. Noter que les HDR* signifient que la charge utile du message est chiffrée.

''Main Mode'' fournit la propriété de ''Perfect Forward Secrecy'' (grâce à Diffie-Hellman) et assure l'anonymat des entités en présence (grâce au chiffrement des deux derniers messages).

''Aggressive Mode'' ne présente pas ces avantages mais est plus rapide car il combine les échanges ci-dessus de façon à ramener le nombre total de messages à trois.

===Phase 2 de IKEv1===

Une fois une association de sécurité ISAKMP mise en place grâce à des échanges de phase 1, Quick Mode est utilisé pour négocier des associations de sécurité IPsec (cf. figure Echanges - Phase 2 d'IKEv1 (''quick mode'')). Chaque négociation aboutit à deux SA symétriques, une dans chaque sens de la communication. Plus précisément, les échanges composant ce mode ont les rôles suivants :

[[image:CS137.gif]]

* Négocier un ensemble de paramètres IPsec (paquet de SA).
* Échanger des nombres aléatoires, utilisés pour générer une nouvelle clé qui dérive de celle du SA ISAKMP. De façon optionnelle, il est possible d'avoir recours à un nouvel échange Diffie-Hellman, afin d'accéder à la propriété de ''Perfect Forward Secrecy'', qui n'est pas fournie si on se contente de générer une nouvelle clé à partir de l'ancienne et des aléas.
* Optionnellement, identifier le trafic que ce paquet de SA protégera, au moyen de sélecteurs (blocs optionnels <tt>IDi</tt> et <tt>IDr</tt> ; en leur absence, les adresses IP des interlocuteurs sont utilisées).

Noter que les négociations de phase 1 visant à se réauthentifier entre équipements et à s'échanger de nouvelles clés secrètes sont rarement faites, tandis que celles de phase 2 sont beaucoup plus courantes. Pour exemple, une phase 1 peut être exécutée une fois par jour, voire une fois par semaine, tandis qu'une phase 2 est exécutée une fois toutes les quelques minutes.

===Interactions entre IKE et IPsec===

Les interactions entre IKE et IPsec sont représentées par le schéma de la figure Interactions de IKEv1 avec IPsec. Deux types de traitement sont envisagés :

[[image:CS138.gif]]

* Trafic sortant
:Lorsque la couche IPsec reçoit des données à envoyer, elle consulte ses bases de données SPD et SAD pour savoir comment traiter ces données et si l'association de sécurité existe déjà. Si l'association de sécurité existe, elle est utilisée pour traiter le trafic en question. Dans le cas contraire, IPsec fait appel à IKE pour établir une nouvelle association de sécurité avec les caractéristiques requises.
* Trafic entrant
:Lorsque la couche IPsec reçoit un paquet en provenance du réseau, elle examine les extensions du paquet. Elle déduit si le paquet est protégé par IPsec et si oui, les indices du ou des associations de sécurité à appliquer. Elle consulte alors le SAD pour connaître les paramètres à utiliser pour la vérification et/ou le déchiffrement du paquet. Une fois le paquet authentifié et déchiffré, le SPD est consulté pour vérifier que le paquet en question répondait bien aux critères du SA qui le protégeait. Dans le cas où le paquet reçu est un paquet IP classique, le SPD permet également de savoir s'il a néanmoins le droit de passer. En particulier, les paquets IKE doivent avoir le droit de passer afin de pouvoir être traités par IKE, qui sera seul juge de leur validité.
Template used on this page:
Template:Suivi (view source)
Return to Echanges ISAKMP/IKEv1.
Retrieved from "http://livre.g6.asso.fr/index.php/Echanges_ISAKMP/IKEv1"
Association G6

View source for Echanges ISAKMP/IKEv1

From Livre IPv6

Views

Personal tools

Navigation

Search

Tools
