VPN et IPsec

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 patches 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 :

  • les données transitant sont chiffrées (confidentialité) et protégées (intégrité)
  • les 2 extrémités sont authentifiées
  • les adresses sources et destinations sont chiffrées, avec IPSec (IP dans IPSec)
  • ils peuvent présenter, suivant le protocole, des qualités anti-rejeux ou empêcher les attaques type man-in-the-middle.


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 :

  • La modification de la stack IP du noyau reste la méthode la plus directe et sans doute la plus compliquée. Cette méthode est appliquable à tout type d’entités (hôtes ou passerelles).
  • La « Bump-In-The-Stack » (BITS) revient à séparer les routines de traitement IPSec des routines habituelles de la stack IP (le code spécifique à IPSec vient en fait s’intercaler entre la couche réseau et la couche liaison/physique, d’où le nom de la méthode). Certains éléments restent tout de même à modifier dans cette stack, comme la fragmentation et le réassemblage des paquets (processus hautement sensibles pour IPSec). Néanmoins, le noyau reste intact dans ce type d’implémentation. Là encore, cette méthode est appliquable à tout type d’entités (hôtes ou passerelles).
  • La « Bump-In-The-Wire » (BITW) revient à déporter le traitement d’IPSec -et donc le code- dans un élément dédié placé en amont sur le réseau (d’où son nom), à l’extérieur de la machine. Un tel élément peut être soit une « boite » dédiée, soit un firewall, un routeur, etc. Suivant son type, cette méthode ne s’appliquera pas à tout type d’hôtes.


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 :

  • Authentification des extrémités : cette authentification mutuelle permet à chacun de s’assurer de l’identité de son interlocuteur. Rappelons tout de même qu’IPSec est un protocole de niveau 3 et qu’il ne fournit donc qu’une authentification de niveau égal, c’est-à-dire une authentification des machines mettant en oeuvre le protocole plutôt que des personnes utilisant réellement la machine. Nous verrons techniquement comme l’authentification est effectuée dans les paragraphes suivants.
  • Confidentialité des données échangées : IPSec permet si on le désire de chiffrer le contenu de chaque paquet IP pour éviter que quiconque ne le lise.
  • Authenticité des données : IPSec permet de s’assurer, pour chaque paquet échangé, qu’il a bien été émis par la bonne machine et qu’il est bien à destination de la seconde machine.
  • Intégrité des données échangées : IPSec permet de s’assurer qu’aucun paquet n’a subit de modification quelconque (attaque dite active) durant son trajet.
  • Protection contre les écoutes et analyses de trafic : IPSec permet de chiffrer les adresses IP réelles de la source et de la destination, ainsi que tout l’en-tête IP correspondant. C’est le mode de tunneling, qui empêche tout attaquant à l’écoute d’inférer des informations sur les identités réelles des extrémités du tunnel, sur les protocoles utilisés au-dessus d’IPSec, sur l’application utilisant le tunnel (timing-attacks et autres)…
  • Protection contre le rejeu : IPSec permet de se prémunir contre les attaques consistant à capturer un ou plusieurs paquets dans le but de les envoyer à nouveau (sans pour autant les avoir déchiffrés) pour bénéficier des même avantages que l’envoyeur initial.


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 :

  • Les adresses de source et de destination : que ce soit unicast, anycast (IPv6), broadcast (IPv4) ou multicast; que ce soit un intervalle d’adressage ou un masque.
  • Un nom sous forme standard (X500 ou DNS) ce qui permet entre autres d’avoir des SAs dédiées à des utilisateurs/hôtes.
  • Le protocole de transport (UDP/TCP principalement)
  • Les ports source et destination, ce qui permet de limiter la SA à un certain type de trafic voire à une session.

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 :

  • Données et paramètres d’authentification : pour AH ou ESP, algorithmes, clés…
  • Données et paramètres de confidentialité : pour AH ou ESP, algorithmes, clés, vecteurs d’initialisation (IV), …
  • Données et paramètres d’anti-rejeu : nombres de séquence, compteurs divers, fenêtres d’anti-rejeu…
  • Type d’en-tête IPSec : modes Transport, Tunnel ou les 2
  • Durée de vie de la SA : temps ou quantité maximale de données à protéger
  • Options de fragmentation

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.

    • La première phase vise à établir la clé mère initiale, SKEYID. Il existe pour cela 3 alternatives suivant les possibilités des parties en présence :
      • Le mode Secret Partagé nécessite qu’un secret soit déjà connu et partagé entre les entités. On l’appelle le « pre-shared secret ». Il va servir de graine à l’élaboration de la clé mère qui va elle-même servir lors de l’authentification finale.
      • Le mode Chiffrement asymétrique se base sur du matériel PK pour échanger les données sensibles et donc établir le secret partagé.
      • Le mode Signature peut être qualifié d’hybride puisqu’il ne se sert du matériel PK que pour signer et donc authentifier les parties. Le secret partagé est lui établi grâce à Diffie-Hellman.

      Une fois la clé mère établie, SKEYID va être diversifiée en 3 clés filles, SKEYID-a, d et e. Ces clés vont servir à la création du premier tunnel sécurisé entre les entités, le canal IKE ou association de sécurité ISAKMP. Il s’agit grossièrement d’un tunnel « administratif »; SKEYID-a est utilisée pour l’authentification dans cette association, SKEYID-e sert au chiffrement et SKEYID-d sera la clé mère des autres associations de sécurité (voir la phase 2).

      Les 3 méthodes présentent des points communs, notamment (et c’est logique) au niveau fonctionnel. Les premiers échanges permettent de définir l’association de sécurité. La deuxième catégorie d’échanges permet d’établir le secret partagé. La troisième et dernière section du handshake permet d’authentifier les parties et de valider tous les échanges précédents (et SKEYID par la même occasion).
      Dans cette première phase, le mode aggressif a pour but de diminuer les échanges en forçant certains paramètres.

 

  • La deuxième phase est également appelée Quick Mode. Elle a pour but d’établir les tunnels (et les associations de sécurité correspondantes) servant au transfert des données. Notez qu’un tunnel est unidirectionnel et qu’il faut donc en établir 2 pour un échange full-duplex. Les mécanismes propres à cette phase sont grossièrement semblables à ceux de la phase précédente, à l’exception de quelques points.
    Parmi ces points, citons le fait que SKEYID-d rentre comme prévu dans le matériel de génération des clés. D’autre part, il existe une option appelée Perfect Secrecy Mode (PFS) qui force les parties à échanger de nouveaux secrets supplémentaires dans le but d’éviter que toutes les clés du système ne dépendent d’une seule et même clé mère (SKEYID).

Notez enfin qu’IKE nécessite l’implémentation des algorithmes et méthodes suivants (set minimal à des fins de compatibilité) :

  • Chiffrement : DES en mode CBC (avec test sur les valeurs de clés afin d’éliminer toute clé dite faible ou semi-faible)
  • Hachage : MD5 et SHA-1
  • Diffie-Hellman

Pour être complets, citons les algorithmes conseillés :

  • Chiffrement : 3DES
  • Hachage : Tiger
  • DSA, RSA


Le protocole d’authentification AH

Le protocole AH (Authentication Header) fournit les services de sécurité suivants :

  • Intégrité en mode non-connecté (voir l’article introduisant la sécurité informatique)
  • Authentification des données
  • Anti-rejeu (optionnel)

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 :

  • spoofing et autres modifications des paquets IP
  • rejeux
  • DoS quand ils sont basés sur la charge impliquée par les calculs cryptographiques (la vérification d’intégrité n’intervient qu’après)


Le protocole de confidentialité ESP

Le protocole ESP (Encapsulating Security Payload) fournit les services de sécurité suivants :

  • Confidentialité
  • Protection contre de l’analyse de trafic
  • Intégrité en mode non-connecté (comme AH)
  • Authentification des données (comme AH)
  • Anti-rejeu (comme AH)

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 :

  • espionnage et autres divulgations d’informations
  • rejeux (optionnel)
  • analyse de trafic (optionnel)


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 :

  • Adresses IP de source et de destination, masques, intervalles…
  • Ports de source et de destination
  • Protocole supérieur
  • Utilisateur ou identifiant de système (ou certificats X.509 réutilisés par les SAs…)


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) :

  • Numéros de séquence étendus (64 bits): cela est rendu nécessaire par l’utilisation d’algorithmes beaucoup plus performants et des débits gigantesques (Gbit/s).
  • Rejet d’AH au rang de fonctionnalité optionnelle.
  • Amélioration des sélecteurs de SPD.
  • Nouveaux protocoles d’échanges de clés supportés (IKEv2, Sigma, JFK…)
  • Simplification du design et amélioration de la robustesse du protocole (DoS…)
  • Support d’AES en mode CBC.
  • Nouveaux modes d’intégrité seule.

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 :

  • IPSec et NAT (utilisation d’UDP ou autres solutions, voir le tunneling)
  • Langages standards de police de sécurité et négociations inter-domaines
  • Protocoles de découverte des passerelles de sécurité
  • …


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.

Laisser un commentaire