Extension de confidentialité ESP

Table des matières

Echanges ISAKMP/IKEv1

Les extensions AH et ESP ont recours à des mécanismes cryptographiques pour protéger les échanges et ont donc besoin de clés de chiffrement. L'un des problèmes fondamentaux d'utilisation de la cryptographie est la gestion de ces clés. Dans le cadre d'IPsec, les clés de chiffrement sont gérées, au même titre que les autres paramètres relatifs à la protection des échanges, par le biais des associations de sécurité.

Il existe deux approches de gestion des associations de sécurité. La plus simple est la gestion manuelle, qui consiste à laisser les individus configurer manuellement chaque équipement de sécurité avec les paramètres appropriés et notamment les clés. Si cette approche s'avère relativement pratique dans un environnement statique et de petite taille, elle ne convient plus pour un réseau de taille importante. De plus, cette méthode implique une définition totalement statique des associations de sécurité et un non-renouvellement des clés.

La seconde approche est la gestion automatique des associations de sécurité au moyen d'un protocole appelé ISAKMP (Internet Security Association and Key Management Protocol) définit dans le RFC 2408 qui fournit un cadre générique pour la négociation, la modification et la destruction des SA, ainsi que pour le format de leurs attributs. Comme le montre la See Architecture d'ISAKMP et IKE, ISAKMP est indépendant du protocole d'échange de clés et du protocole pour lequel on souhaite négocier une association.

Ainsi, dans le cadre de la standardisation IPsec, ISAKMP est associé en partie aux protocoles d'échanges de clés SKEME et Oakley pour donner un protocole final du nom de Internet Key Exchange ou IKE [RFC 2409]. Ce protocole couvre pour le moment uniquement les situations d'unicast, mais l'IETF travaille à définir une distribution de clés multicast.

Plus précisément, pour gérer les associations de sécurité et les clés de chiffrement dans un environnement IPsec, le protocole IKE fait appel aux éléments suivants :

• un protocole de gestion des associations de sécurité comme ISAKMP (Internet Security Association and Key Management Protocol) [RFC 2408], qui définit des formats de paquets permettant de créer, modifier et détruire des associations de sécurité. Ce protocole sert également de support pour l'échange de clés préconisé par les protocoles de gestion de clés. Il assure aussi l'authentification des partenaires d'une communication ;
• un protocole d'échange de clés de session basé sur SKEME et Oakley qui repose sur la génération de secrets partagés Diffie-Hellman. Plus exactement, IKE utilise certains des modes définis par Oakley et emprunte à SKEME son utilisation du chiffrement à clé publique pour l'authentification et sa méthode de changement de clef rapide par échanges d'aléas ;
• un domaine d'interprétation ou DOI (Domain of Interpretation) [RFC 2407] qui définit tous les paramètres propres à l'environnement IPsec, à savoir les protocoles d'échanges de clés, les paramètres d'associations de sécurité à négocier,... ;
• les clés utiles lors de l'authentification mutuelle des équipements IPsec qui intervient en préalable à toute négociation d'association de sécurité. Ces clés peuvent être des clés partagées (pre-shared key) préconfigurées par l'administrateur, ou bien des clés privées/publiques personnelles à chaque équipement IPsec et préchargées dans les équipements, ou bien encore un certificat électronique géré par une infrastructure à clés publiques (PKI : Public Key Infrastructure) telle que décrite See PKI : principe et lacunes actuelles.

Deux versions de IKE vont bientôt coexister et une description de ces deux versions est proposée ci-après.

Architecture

ISAKMP offre un cadre générique de gestion des associations de sécurité en ce sens qu'il s'applique à n'importe quel protocole implémentant de la sécurité : IPsec, TLS (Transport Layer Security), SSL (Secure Socket Layer). Ceci est possible car ISAKMP est prévu pour fonctionner au-dessus d'IP si bien que les informations relatives à la gestion des associations de sécurité et des clés sont transportées au moyen de paquets ISAKMP indépendamment du protocole en faveur duquel la négociation a lieu. ISAKMP peut être placé directement au-dessus d'IP ou au-dessus de tout protocole de niveau transport. Il s'est notamment vu attribuer le port 500 sur UDP par l'IANA.

Les messages d'ISAKMP sont constitués d'un en-tête suivi d'un nombre variable de blocs. Ces blocs (payloads) sont les briques de base d'ISAKMP et incluent des informations relatives :

• paramètres de sécurité à négocier (bloc Security Association ou SA, Proposal ou P, Transform ou T),
• aux clés de session à convenir (Key Exchange ou KE),
• aux identités des entités (ID), aux certificats (CERT, Certificate Request ou CERTREQ),
• à l'authentification (HASH, SIG, NONCE où NONCE contient un nombre généré aléatoirement),
• aux messages d'erreurs (notification ou N),
• aux associations de sécurité à supprimer (Delete) et
• au constructeur d'équipement/logiciel de sécurité (Vendor ID).

ISAKMP définit un cadre pour négocier les associations de sécurité, mais n'impose rien quant aux paramètres qui les composent. Un document appelé "domaine d'interprétation" (DOI : Domain of Interpretation) définit la syntaxe des paramètres, les types d'échanges et les conventions de nommage relatifs à l'emploi d'ISAKMP dans un cadre particulier. Un identifiant de DOI est par conséquent utilisé pour interpréter et synthétiser la charge utile des messages ISAKMP dans le contexte d'un DOI donné (cf. See Présentation symbolique du domaine d'interprétation IPsec). Le DOI IPsec documenté dans le RFC 2407 est identifié par le numéro 1.

ISAKMP offre l'avantage d'être indépendant de la méthode de génération des clés et des algorithmes de chiffrement et d'authentification utilisés. Il est donc indépendant de tout protocole d'échange de clé, ce qui permet de séparer clairement les détails de la gestion des associations de sécurité des détails de l'échange de clé. Dans le contexte IPsec, les protocoles d'échange de clés utilisés sont SKEME/Oakley.

A la fin de la négociation, comme le montre la figure Architecture d'ISAKMP et IKE, ISAKMP communique le résultat au module intéressé par le biais d'une API (Application Programming Interface). Même si aujourd'hui, ISAKMP est exclusivement utilisé pour configurer le module IPsec - ESP/AH, il pourrait tout à fait servir à la configuration de modules SSL/TLS ou autres.

Extension de confidentialité ESP

Table des matières

Echanges ISAKMP/IKEv1