Société de Sécurité Informatique - Audit Firewall Appliances
La sécurité informatique - La sécurité des informations

IPSec : Internet Protocol Security


Overview


IPSec (Internet Protocol Security, RFC 2401) est un protocole de la couche 3 du modèle OSI, tout comme IP; il fut à l'origine développé dans le cadre de la version future de ce dernier protocole, à savoir IPv6. Or, si IPSec existe depuis quelques temps déjà, IPv6 n'est quant à lui pas encore déployé à grande échelle, ce qui aurait put empêcher l'utilisation d'IPSec. Mais il n'en est rien puisque ce dernier a été porté vers la version actuelle d'IP (IPv4) et est maintenant disponible pour tous (les plus récents patchs de sécurité de Windows 2000 l'incluent, et des distributions libres comme FreeSwan pour Linux existent également).


Présentation générale


IPSec est un protocole destiné à fournir différents services de sécurité. Il propose ainsi plusieurs choix et options qui lui permettent de répondre de façon adaptée aux besoins des entreprises, nomades, extranets, particuliers, etc... Néanmoins, son intérêt principal reste sans conteste son mode dit de tunneling, c'est-à-dire d'encapsulation d'IP qui lui permet entre autres choses de créer des réseaux privés virtuels (ou VPN en anglais). Cette technologie à pour but d'établir une communication sécurisée (le tunnel) entre des entités éloignées, séparées par un réseau non sécurisé voir public comme Internet, et ce de manière quasi-transparente si on le désire. Dans l'article qui suit, c'est ce mode d'IPSec, le mode tunneling, qui sera décrit en priorité.

De manière succincte, citons quelques propriétés générales des tunnels destinés aux VPNs :

Il ne faut pas non plus négliger les aspects pratiques tel que la charge processeur due au chiffrement, le débit théorique possible, l'overhead induit et donc le débit effectif... De plus IPsec n'est pas le seul protocole permettant d'établir des tunnels, il en existe d'autres comme les "point-à-point" tel que L2TP, L2F ou encore PPTP qui peuvent induire un overhead non négligeable surtout lors d'encapsulations successives (L2TPoATM avec AAL5, L2TPoEthernet, L2TPoUDP...). Voir la fiche consacrée au tunneling pour plus de détails.


Les implémentations d'IPSec


D'un point de vue pratique, IPSec est un protocole relativement difficile à implémenter d'une part à cause de sa complexité intrinsèque (multiples sous-protocoles...) et d'autre part à cause de ses interactions avec les processus réseau courants. S'il a été conçu avec des critères tel que l'interopérablité en tête, IPSec n'en reste pas moins un protocole de niveau 3 qui ne supporte aucune modification ni altération à ce niveau (ou supérieur) une fois ses paquets créés. Ainsi, de nombreux points restent problématiques comme l'interopérabilité avec le NAT (modifications de niveau 3) ou son intégration dans le kernel de l'hôte. A ce sujet, il existe 3 variantes :



Les services proposés par IPSec


Revenons à présent au protocole en lui-même. Nous avons cité précédemment quelles étaient les propriétés basiques des tunnels de chiffrement, et ce indépendamment du protocole utilisé. Citons à présent quels sont les services de sécurité proposés par IPSec, services qui permettent notamment d'assurer les propriétés des tunnels et VPNs citées précédemment :



Description des sous-protocoles


IPSec repose en fait sur plusieurs protocoles différents -dont certains existent à part entière hors d'IPSec- qui lui offrent en retour une grande souplesse d'utilisation.

Le proctocole initial et principal est le protocole IKE (Internet Key Exchange, RFC 2409). Appliqué à IPSec, ce protocole a pour objectif dans un premier temps d'établir un premier tunnel entre les 2 machines (le tunnel IKE), que l'on pourra qualifier de "tunnel administratif". C'est la phase 1 du protocole IKE. Ce protocole est dit administratif car il ne sert pas à la transmission des données utilisateur; il est utilisé pour gérer les tunnels secondaires, leur création, le rafraîchissement des clés, etc... La phase 2 du protocole IKE consiste en effet à établir autant de tunnels secondaires que nécessaire pour la transmission des données utilisateur entre les 2 machines. Notez qu'il est possible de recourir à une authentification manuelle à la place d'IKE, mais comme ce dernier permet bien plus de choses que de l'authentification, cela s'avère beaucoup plus difficile à utiliser. Le protocole IKE est décrit dans le paragraphe sur l'initialisation d'IPSec.

Les tunnels destinés aux échanges de données vont s'appuyer sur 2 protocoles différents suivant les besoins en sécurité des utilisateurs. Le premier est le protocole AH (Authentication Header, RFC 2402) qui vise à établir l'identité des extrémités de façon certaine. Il ne garantit aucune confidentialité (chiffrement) des données. Le deuxième protocole est le protocole ESP (Encapsulating Security Payload, RFC 2406) qui a pour but de chiffrer les données, avec ou sans les entêtes des paquets si l'on souhaite le mode tunneling. Il garantit également l'authenticité des données et, à ce niveau, peut introduire de la redondance par rapport à AH. Les aspects cryptographiques de ces protocoles seront décrits dans un paragraphe dédié.

Ces 2 protocoles, AH et ESP, peuvent d'autre part être utilisés séparément ou combinés, comme expliqué ci-dessous.


Description des modes d'IPSec


Bien que cet article soit focalisé sur le mode tunneling d'IPSec, il est intéressant de mentionner les autres modes disponibles :

Le mode Transport ne modifie pas l'en-tête initial; il s'intercale entre le protocole réseau (IP) et le protocole de transport (TCP, UDP...). Plusieurs variantes existent, conformément aux protocoles décrits plus haut :

Le mode Tunnel remplace les en-têtes IP originaux et encapsule la totalité du paquet IP. Par exemple, l'adresse IPA externe pourra être celle de la passerelle de sécurité implémentant IPSec, et l'adresse IPB interne sera celle de la machine finale, sur le réseau derrière la passerelle.

Le mode de Nesting est hybride puisqu'il utilise les 2 modes cités précédemment. Il s'agit bien d'encapsuler de l'IPSec dans de l'IPSec; nous verrons plus tard les répercussions au niveau implémentation (bundle de SAs) :



Les Associations de Sécurité (SA)


Avant d'aller plus loin, il parait important d'expliciter un terme qui revient assez couramment lorsque l'on parle d'IPSec : l'Association de Sécurité ou SA.
Une SA est un élément (d'un point de vue physique, un record dans une base de données, la SAD) qui contient toutes les informations requises pour caractériser et échanger des données à protéger. Ainsi, chaque SA contient des éléments permettant de déterminer à quel type de trafic ou paquet elle s'applique. On distingue :
Tous ces éléments sont appelés sélecteurs et permettent d'identifier quelle SA s'applique à tel ou tel trafic. Néanmoins, la fonction primaire de la SA est d'indiquer quels traitements doivent être appliqués au trafic identifié précédemment. On distingue les éléments suivants :
Les champs présentés ici montrent à quel point une SA peut-être précise sur le type de données sur lequel elle s'applique. On parle alors de granularité. Nous verrons plus tard les interactions entre la SAD et une autre base de données, la SPD, qui permettent d'affiner encore plus le traitement des flux.


Initialisation d'IPSec (IKE)


IKE a été conçu sur la base de multiples exemples : ISAKMP, SKEME et Oakley. Nous ne rentrerons pas ici dans les détails de ces protocoles ou infrastructures d'échange de clés. Néanmoins, il faut mentionner le fait qu'IKE a pour vocation principale d'authentifier les différentes parties et de leur fournir du matériel pour générer des clés, et ce dans le cadre d'associations de sécurité ("security associations", c'est-à-dire un ensemble de règles et de clés utilisées pour protéger des informations).
Voyons l'organigramme fonctionnel général du protocole appliqué à IPSec :


Ce diagramme illustre le fait qu'IKE employé dans le cadre d'IPSec se compose de plusieurs phases.

Notez enfin qu'IKE nécessite l'implémentation des algorithmes et méthodes suivants (set minimal à des fins de compatibilité) :
Pour être complets, citons les algorithmes conseillés :



Le protocole d'authentification AH


Le protocole AH (Authentication Header) fournit les services de sécurité suivants :
L'en-tête AH se compose de 6 champs comme le décrit l'image suivante :


Un des plus importants est sans aucun doute l'ICV (Integrity Check Value, "Données d'authentification" ci-dessus) qui est le résultat d'un procédé cryptographique sur les données à protéger et qui va permettre de vérifier l'intégrité de celles-ci. La taille totale de l'en-tête est de 24 octets; l'ICV est bien entendu paddé pour atteindre une taille constante (car les algorithmes utilisés peuvent différer).

En conclusion, AH permet de se protéger contre les attaques de type :



Le protocole de confidentialité ESP


Le protocole ESP (Encapsulating Security Payload) fournit les services de sécurité suivants :
On peut voir tout de suite qu'ESP couvre les services offerts par AH, et on peut se demander pourquoi AH est utilisé et pourquoi l'on complique ainsi un protocole qui l'est déjà bien assez. C'est en effet une question qui est d'actualité mais néanmoins il faut souligner le fait qu'AH offre des services plus complets qu'ESP car il est le seul à protéger l'en-tête du paquet (en-tête original en mode Transport, en-tête IPSec en mode Tunnel). ESP ne protège que les données (c'est-à-dire tout au plus l'en-tête original en mode Tunnel).

L'en-tête ESP se compose de 7 champs (dont 2 optionnels) comme le décrit l'image suivante :


Nous ne rentrerons pas dans les détails de chaque champ ici, mais nous invitons les lecteurs à consulter la RFC correspondante pour plus d'informations sur le sujet. Très brièvement, le chiffrement sera appliqué aux données utiles jusqu'au champ NEXT inclus (ce champ contient un identifiant du protocole supérieur, au niveau 4). Comme les données utiles ne sont pas pré-définies, leur longueur peut varier grandement et un padding assez important est requis. Il est obligatoire et sa longueur est explicitée dans le champ PAD LEN. Les données d'authentification protègent les données du champ SPI au champ NEXT inclus; en cas d'utilisation des 2 mécanismes simultanément, le chiffrement est effectué en premier suivi du calcul des données d'intégrité. Cela a pour résultat d'éviter des attaques par déni de service au déchiffrement (comme démontré récemment à Crypto'01), ainsi que de permettre d'effectuer les 2 opérations en parallèle (à la réception).

En conclusion, ESP permet de se protéger contre les attaques de type :



La SPD


La SPD (Security Policy Database) est une liste ordonnée d'entrées contenant des critères de contrôle d'accès, similaires à des règles de pare-feux. La SPD est statique par défaut car l'ordre des enregistrements qu'elle contient est très important; en effet, plusieurs règles peuvent s'appliquer à un même paquet en théorie mais seule la première sera réellement effective, d'où l'importance de l'ordre. Il est pourtant possible d'avoir des SPDs dynamiques, mais cela requiert un réordonnancement à la volée des entrées.
Il y a 2 SPDs par interfaces, une pour le trafic entrant, l'autre pour le trafic sortant. Chaque entrée de ces SPDs précise un traitement à appliquer au paquet pour lequel la règle s'applique (quand le critère de sélection ou sélecteur est vrai); ces traitements sont DROP (jette), BYPASS (laisse passer) ou IPSec PROCESS (traitement avec IPSec). Ce dernier cas précise en outre les paramètres propres à IPSec tel que l'algorithme, etc...

Tout comme les règles d'un pare-feu ou encore les SAs vues précédemment, les sélecteurs sont les suivants :



Evolutions du standard


Comme on peut s'en douter, les standards relatifs à IPSec sont en constante évolution afin d'intégrer entre autres les derniers standards cryptographiques (AES...). Voici une liste non-exhaustive des tendances actuelles (au début 2002) :
D'autre part, de nombreux groupes (à l'IETF par exemple) travaillent actuellement sur des problèmes liés à IPSec afin d'améliorer sont intégration dans tous les environnements :



Conclusion


IPSec est comme nous l'avons vu un assemblage de plusieurs protocoles et mécanismes ce qui le rend techniquement très complexe. Je vous invite à consulter les RFCs correspondantes pour toute question précise à son sujet.
IPSec est d'autre part en constante évolution car il est soutenu par une grande population technique et scientifique. Il existe de nombreux drafts à son sujet ou sur des sujets annexes comme l'interopérabilité avec les dispositifs de translation d'adresse.
Rappelons enfin qu'un des objectifs de cette fiche est également de soulever les limites de ce protocole; il est bon de savoir par exemple qu'IPSec ne permet pas d'authentifier les personnes et ne peut donc pas servir à sécuriser des transactions. De ce point de vue, ce n'est pas un concurrent de SSL.

SoGoodToBe
02 Septembre 2002

Partagez cet article

Envoyer cet article par Email ! Imprimer cet article ! Exporter cet article en PDF ! Facebook Twitter Google Bookmarks

SecuriteInfo.com est une entreprise française de sécurité informatique. Nous proposons différentes solutions matérielles et prestations de services permettant de sécuriser les données des Systèmes d'Information d'entreprises ou de collectivités.
Twitter SecuriteInfo.com
Facebook SecuriteInfo.com
BOINC calcul scientifique
© 2004-2016 - Tous droits réservés - SecuriteInfo.com