guill.net - La page des réseaux

Introduction

Pour sécuriser les échanges ayant lieu sur un réseau TCP/IP, il existe plusieurs approches :
- niveau applicatif (PGP)
- niveau transport (protocoles TLS/SSL, SSH)
- niveau physique (boîtiers chiffrant).

IPsec vise à sécuriser les échanges au niveau de la couche réseau. Le réseau IPv4 étant largement déployé et la migration complète vers IPv6 nécessitant encore beaucoup de temps, il est vite apparu intéressant de définir des mécanismes de sécurité qui soient communs à la fois à IPv4 et IPv6. Ces mécanismes sont couramment désignés par le terme IPsec pour IP Security Protocols. IPsec fournit donc : - confidentialité et protection contre l'analyse du trafic, - authentification des données (et de leur origine), - intégrité des données (en mode non connecté), - protection contre le rejeu, - contrôle d'accès. IPsec est une extension de sécurité pour le protocole Internet IP. Il peut être mis en œuvre sur tous les équipements du réseau et de nombreux fournisseurs l'intègrent désormais dans leurs produits. Exemple d'utilisation : Les réseaux privés virtuels ou VPN ou bien la sécurisation des accès distants à un intranet.

IPsec fonctionne autour de bases de données de politiques de sécurité dont le fonctionnement est décrit ci-après.

Principe du fonctionnement SA / SAD /SPD
 

SA : ‘Security Association’. L’association de sécurité IPsec est une connexion qui fournit des services de sécurité au trafic qu’elle transporte. Il s’agit d’une structure de données servant à stocker l’ensemble des paramètres associés à une communication donnée. Une SA est unidirectionnelle ; en conséquence, protéger les deux sens d’une communication classique requiert deux associations, une dans chaque sens. Les services de sécurité sont fournis par l’utilisation soit de AH soit de ESP (vus plus loin). Le rôle d’une SA est donc de consigner, pour chaque adresse IP avec laquelle l’implémentation IPsec peut communiquer, les informations suivantes :
- index de la SA appelé SPI (pour Security Parameter Index) choisi par le récepteur
- un numéro de séquence, indicateur utilisé pour le service d’anti-rejeu
- une fenêtre d’anti-rejeu : compteur 32 bits
- dépassement de séquence
- paramètres d’authentification (algorithmes et clés)
- paramètres de chiffrement (idem)
- temps de vie de la SA
- mode du protocole IPsec (tunnel ou transport)
- …

Chaque association est identifiée de manière unique à l’aide d’un triplet composé de :
- l’adresse de destination des paquets
- l’identifiant du protocole de sécurité (AH ou ESP)
- le SPI

SAD : pour gérer les associations de sécurité actives, on utilise une base de données des associations de sécurité (Security Association Database, SAD). Elle contient tous les paramètres relatifs à chaque SA et sera consultée pour savoir comment traiter chaque paquet reçu ou à émettre.

SPD : les protections offertes par IPsec sont basées sur des choix définis dans une base de données de politique de sécurité (Security Policy Databas, SPD). Cette base de données est établie et maintenue par un utilisateur, un administrateur ou une application mise en place par ceux-ci. Elle permet de décider, pour chaque paquet, s’il se verra apporter des services de sécurité, s’il sera autorisé à passer outre ou sera rejeté.

Ces services sont basés sur des mécanismes cryptographiques. Pour cela, IPsec fait appel à deux protocoles de sécurité qui viennent s'ajouter au protocole IP classique : il s'agit des protocoles AH et ESP. IPsec offre ainsi deux possibilités d'encapsulation distinctes. Toutefois, l'évolution de ce protocole fait que ESP assure désormais l'ensemble des fonctionnalités des deux mécanismes.

Au-delà de AH et ESP, l'IETF a jugé judicieux d'offrir un service supplémentaire appelé chiffrement en mode Fast Forward qui conserve la même taille de datagrammes et ainsi des performances optimales. Cependant, il protège en confidentialité uniquement. L'en-tête IP et la longueur du datagramme restent inchangés (sauf éventuellement le champ d'options IP qui peut être chiffré).

Les SA contiennent tous les paramètres nécessaires à IPsec, notamment les clés utilisées. La gestion des clés pour IPsec n’est liée aux autres mécanismes de sécurité de IPsec que par le biais des SA. Une SA peut être configurée manuellement dans le cas d’une situation simple, mais la règle générale consiste à utiliser un protocole spécifique qui permet la négociation dynamique des SA et notamment l’échange des clés de session.
Le protocole de négociation des SA, développé pour Ipsec, est le protocole de gestion des clés et des associations de sécurité pour Internet (Internet Security Association and Key Management Protocol, ISAKMP). ISAKMP est en fait inutilisable seul (il s’agit d’un cadre générique qui permet l’utilisation de plusieurs protocoles d’échange de clé). Dans le cadre de la standardisation de IPsec, ISAKMP est associé à une parti des protocoles SKEME et Oakley pour donner un protocole final du nom de Internet Key Exchange, IKE.

Reprenons maintenant le schéma précédent sur deux exemples :

Exemple 1 : trafic sortant

Lorsque la couche IPsec reçoit des données à envoyer, elle commence par consulter la base de données des politiques de sécurité (SPD) pour savoir comment traiter ces données. Si cette base lui indique que le trafic doit se voir appliquer des mécanismes de sécurité, elle récupère les caractéristiques requises pour la SA correspondante et va consulter la base des SA (SAD). Si la SA nécessaire existe déjà, elle est utilisée pour traiter le trafic en question. Dans le cas contraire, IPsec fait appel à IKE pour établir une nouvelle SA avec les caractéristiques requises.

Exemple 2 : trafic entrant

Lorsque la couche IPsec reçoit un paquet en provenance du réseau, elle examine l’en-tête pour savoir si ce paquet s’est vu appliquer un ou plusieurs services IPsec et si oui, quelles sont les références de la SA. Elle consulte alors la SAD pour connaître les paramètres à utiliser pour la vérification et/ou le déchiffrement du paquet. Une fois le paquet vérifié et/ou déchiffré, la SPD est consultée pour savoir si l’association de sécurité appliquée au paquet correspondait bien à celle requise par les politiques de sécurité. Dans le cas où le paquet reçu est un paquet IP classique, la SPD permet de savoir s’il a néanmoins le droit de passer. Par exemple, les paquets IKE sont une exception. Ils sont traités par IKE, qui peut envoyer des alertes administratives en cas de tentative de connexion infructueuses.

Protocole AH (Authentication Header)

AH est conçu pour assurer l'intégrité en mode non connecté et l'authentification de l'origine des datagrammes IP sans chiffrement des données (pas de confidentialité). L'absence de confidentialité permet de s'assurer que ce standard pourra être largement répandu sur Internet, y compris dans les endroits où l'exportation, l'importation ou l'utilisation du chiffrement dans des buts de confidentialité est restreint par la loi.
 

Son principe est d'adjoindre au datagramme IP classique un champ supplémentaire permettant à la réception de vérifier l'authenticité des données incluses dans le datagramme. Ce bloc de données est appelé "valeur de vérification d'intégrité" (Intégrity Check Value, ICV). La protection contre le rejeu se fait grâce à un numéro de séquence.

Mode transport et mode tunnel

Le mode transport prend un flux de niveau transport (couche de niveau 4 du modèle OSI) et réalise les mécanismes de signature et de chiffrement puis transmet les données à la couche IP. Dans ce mode, l'insertion de la couche IPsec est transparente entre TCP et IP. TCP envoie ses données vers IPsec comme il les enverrait vers IPv4.
L'inconvénient de ce mode réside dans le fait que l'en-tête extérieur est produit par la couche IP c'est-à-dire sans masquage d'adresse. De plus, le fait de terminer les traitements par la couche IP ne permet pas de garantir la non-utilisation des options IP potentiellement dangereuses. L'intérêt de ce mode réside dans une relative facilité de mise en œuvre.
Dans le mode tunnel, les données envoyées par l'application traversent la pile de protocole jusqu'à la couche IP incluse, puis sont envoyées vers le module IPsec. L'encapsulation IPsec en mode tunnel permet le masquage d'adresses.

Le mode tunnel est utilisé entre deux passerelles de sécurité (routeur, firewall, …) alors que le mode transport se situe entre deux hôtes.

Protocole ESP (Encapsulating Security Payload)

ESP peut assurer, au choix, un ou plusieurs des services suivants :
- confidentialité des données et protection partielle contre l'analyse du trafic si l'on utilise le mode tunnel
- intégrité des données en mode non connecté et authentification de l'origine des données, protection partielle contre le rejeu.

Contrairement à AH, où l'on se contentait d'ajouter un en-tête supplémentaire au paquet IP, ESP fonctionne suivant le principe de l'encapsulation : les données originales sont chiffrées puis encapsulées.

Encapsulation

Conclusions

Forces et faiblesses du cadre protocolaire IPsec

Avantages :
- Modèle de sécurité flexible et non exhaustif basé sur une boîte à outils modulaire
- Possibilité d'instaurer plusieurs crans de sécurité : chiffrement faible ou fort et/ou authentification
- Services de sécurité totalement transparent pour les applications
 
 Inconvénients :
- Mécanismes de sécurité trop nombreux, engendrant un système complexe
- IPsec interdit la translation d'adresses (Network address translation, NAT)
- L'interaction du protocole IKE avec les infrastructures à clé publique (PKI) est possible mais il reste à normaliser
- Les outils d'administration centralisée des règles de sécurité (Security Policies) font défaut
- Entorses propriétaires nuisibles à l'interopérabilité
- IPsec est limité à l'instauration de VPN entre réseaux (passerelles-serveurs). Le protocole orienté client-serveur IPSRA (IPsec Remote Access) devra s'imposer face à PPTP ou L2TP.