Revision as of 16:23, 13 February 2006

Orientations choisies par l'IETF

Table des matières

Extension d'authentification AH

Une association de sécurité IPsec contient le type d'extension de sécurité à mettre en place sur une communication ainsi que les services et les paramètres de sécurité (algorithmes et clés de chiffrement, données de synchronisation,...) en vue de protéger les échanges de données effectués. Elle doit donc être connue des entités (par exemple : stations, passerelles de sécurité) chargées de la protection de la communication.

Une association de sécurité est identifiée de façon unique par un triplet comprenant un indice de paramètres de sécurité SPI (Security Parameters Index), parfois qualifié de SAID (Security Association IDentifier), l'adresse du destinataire d'un paquet IP et le protocole de sécurité AH ou ESP. Un équipement de sécurité IPv6 peut ainsi participer à plusieurs associations de sécurité et peut protéger une communication avec une ou plusieurs association(s) de sécurité. Si par exemple les deux extensions de sécurité AH et ESP sont utilisées simultanément entre deux équipements de sécurité pour une même communication, il est alors nécessaire que les équipements gèrent deux associations de sécurité distinctes.

Une association de sécurité est unidirectionnelle. Une communication bidirectionnelle passée entre deux stations A et B nécessite donc l'intervention de deux associations de sécurité, celle utilisée par A pour protéger les datagrammes de A vers B et celle utilisée par B pour la protection des datagrammes de B vers A.

Contenu d'une association de sécurité

Une association de sécurité contient entre autres les paramètres suivants :

• l'algorithme d'authentification, les clés de chiffrement,... utilisés pour générer l'extension AH ;
• l'algorithme de chiffrement, les clés de chiffrement, le mode de chiffrement, les paramètres de synchronisation,... utilisés pour générer l'extension ESP ;
• l'algorithme d'authentification, les clés de chiffrement,... utilisés pour générer l'extension ESP si le service d'authentification est sélectionné ;
• la durée de vie de l'association de sécurité : pour éviter que des clés de chiffrement ne soient utilisées trop longtemps, ce qui affaiblirait le niveau de sécurité des communications, il est nécessaire de convenir périodiquement d'une nouvelle association de sécurité ;
• le mode du protocole IPsec, à savoir : tunnel, transport ou wildcard. Le mode wildcard signifie que le choix du mode de protection est déterminé par l'application ; ce mode n'est utilisable qu'à partir d'une station de travail, mais il n'est pas disponible actuellement sur les implémentations courantes, car trop complexe de mise en ?uvre.

Afin qu'une passerelle de sécurité puisse interpréter correctement les extensions de sécurité reçues, l'association de sécurité (c'est-à-dire le SPI) ayant servi à leur construction doit être mentionnée dans chacune des extensions de sécurité.

Choix d'une association de sécurité

Le choix de l'association de sécurité au niveau de la station émettrice ou d'une passerelle de sécurité peut théoriquement dépendre des paramètres suivants (appelés sélecteurs dans le RFC 2401) :

• l'adresse IP de la source locale qui peut être une adresse unicast, anycast, ou multicast, voire un ensemble d'adresses. Si le choix dépend exclusivement de cette adresse, la même association de sécurité est attribuée à deux utilisateurs connectés sur la même station et émettant vers le même destinataire. Cette approche souffre d'un handicap majeur. En effet, un utilisateur malveillant peut déduire la clé utilisée entre deux stations en se connectant sur cette station et en effectuant une attaque du type Chosen Plaintext Attack qui consiste à soumettre un texte en clair particulier à la station et à analyser le texte chiffré correspondant (celui émis sur le réseau) pour trouver la clé de chiffrement utilisée. La connaissance de cette clé lui permet ensuite de déchiffrer tout le trafic échangé entre les deux stations (dans un sens uniquement).
• l'identité de l'utilisateur (par exemple un nom DNS ou X.500). Cette approche est beaucoup plus fiable que l'approche précédente du fait que l'attaque Chosen Plaintext Attack n'est plus réalisable.
• l'identité de l'équipement utilisé (nom DNS ou X.500).
• les numéros de ports source et destination (e.g., TCP/UDP).
• le protocole de niveau transport obtenu par le champ en-tête suivant :
• l'adresse IP de l'équipement distant qui peut être une adresse unicast, anycast, ou multicast, voire un ensemble d'adresses. Les premières générations de passerelles IPsec se contentaient de ce type de sélecteurs, mais les nouvelles versions se sont enrichies en considérant, en plus de l'adresse de destination, les numéros de port de destination.
• le niveau de sensibilité des données (identifié par les étiquettes normalisées IPSO/CIPSO du RFC 1108)

La majorité des équipements IPsec aujourd'hui considère généralement que les sélecteurs sont les adresses IP de destination, les numéros de protocole et numéros de port.

Bases de données

L'IETF conseille aux constructeurs qui souhaiteraient implémenter les IPsec de définir deux bases de données de sécurité afin que l'équipement de sécurité puisse déterminer en deux étapes l'association de sécurité à appliquer pour construire ou extraire les extensions de sécurité. Du fait que ces bases de données dépendent beaucoup du choix de l'implémentation, les constructeurs sont libres de les implémenter ou pas. Les deux bases de données qui permettent, lors de la réception d'un paquet IP, de déterminer l'association de sécurité à appliquer, sont les suivantes :

• le SPD (Security Policy Database) précise, en fonction du "sélecteur" (le critère de sélection d'une association de sécurité) choisi, les actions à effectuer sur un paquet. Trois actions sont possibles :
  • Soit le trafic n'est pas autorisé à être émis par une station, à transiter via une passerelle de sécurité ou à être reçu par une application : il est donc supprimé (discard).
  • Soit le trafic est autorisé mais ne nécessite aucun service de sécurité ; il est alors ignoré par l'ensemble des équipements/logiciel implémentant les IPsec (bypass IPsec).
  • Soit le trafic nécessite une protection IPsec (apply IPsec) auquel cas le SPD spécifie pour chaque sélecteur l'association de sécurité ou les associations de sécurité à appliquer (précisée(s) dans la base de données SAD).
• le SAD (Security Association Database) contient l'ensemble des associations de sécurité et précise pour chacune d'elles, les services et mécanismes de sécurité à appliquer. Ainsi si d'après le SPD, un paquet nécessite une protection, il est facile de retrouver la (les) associations de sécurité à appliquer à l'aide du SPI, de l'adresse de destination et du protocole AH ou ESP sélectionné. Il reste alors à appliquer les services de sécurité adéquats.

La figure Différents bases d'IPsec montre un exemple de bases de données partagées par deux équipements IPsec A et B. La base SPD indique que le trafic émis de A vers B est protégé par ESP en mode tunnel et le trafic de B vers A par AH en mode tunnel. La base SAD précise les outils de mise en oeuvre avec l'algorithme de chiffrement triple DES (3DES) pour ESP et la fonction de hachage HMAC-SHA1 utilisée par ESP et AH.

Évolutions attendues

Le RFC 2401 est en cours de révision avec les travaux en cours sur [RFC2401bis]. Le [[1]] ne change rien fondamentalement au standard, mais définit de façon plus fine les bases de données afin de permettre la mise en oeuvre de scenarios IPsec plus complexes, d'améliorer les performances et de simplifier les implémentations. En effet, elle considère que la base SPD est divisée en trois sous bases de données, SPD-S (S pour Secure) qui répertorie l'ensemble des flux devant être protégés par IPsec, SPD-O (O pour Outbound) qui liste l'ensemble des flux sortants qui ne nécessitent pas de protection ou qui sont interdits et SPD-I (I pour Inbound) qui renseigne sur l'ensemble des flux entrants qui ne nécessitent pas de protection ou qui sont interdits. Ainsi suivant que les paquets entrent ou sortent du réseau, le traitement sera optimisé car il sera fait appel à une base SPD spécialisée (SPD-O ou SPD-I) et au besoin à SPD-S. En plus des bases SPD et SAD, la base PAD (Peer Authorization Database) est définie pour permettre de faire le lien entre le protocole de gestion des associations de sécurité comme IKE (voir le chapitre Gestion des associations et des clés) et la base SPD. Chaque entrée de SPD peut être exprimée à l'aide d'un ou plusieurs ensemble(s) de sélecteurs associés à une liste de plages de valeurs, contrairement au RFC 2401 où un seul sélecteur à la fois était possible. Enfin, une architecture logicielle modulaires est proposée ; elle introduit la notion de module forwarding indépendant du traitement IPsec qui a pour finalité de déterminer l'interface d'acheminement des paquets et ainsi de mettre en oeuvre des traitements IPsec plus complexes sur les paquets. En particulier, il est possible d'appliquer deux traitements IPsec sur un même paquet.

Orientations choisies par l'IETF

Table des matières

Extension d'authentification AH