Memoire Online - Etude des protocoles de sécurité dans le réseau internet

ESP est le second protocole de protection des données qui fait partie de la spécification IPSec. Contrairement à AH, ESP ne protège pas les entêtes des datagrammes IP utilisés pour transmettre les communications. Seules les données sont protégées. En mode transport, il assure :

1' La confidentialité des données (optionnelle) : la partie données des datagrammes IP transmis est chiffrée ;

1' L'authentification (optionnelle, mais obligatoire en l'absence de confidentialité) : la partie données des datagrammes IP reçus ne peut avoir été émise que par l'hôte avec lequel a lieu l'échange IPSec, qui ne peut s'authentifier avec sucées que s'il connaît la clé associée a la communication ESP. Il est également important de savoir que l'absence d'authentification nuit a la confidentialité en la rendant plus vulnérable a certaines attaques actives ;

1' L'intégrité : les données n'ont pas été modifiées depuis leur émission.

En mode tunnel, ces garanties s'appliquent aux données du datagramme dans lequel est encapsulé le trafic utile, donc à la totalité (en-têtes et options inclus) du datagramme encapsulé. Dans ce mode, deux avantages supplémentaires apparaissent :

1' Une confidentialité limitée des flux de données (en mode tunnel uniquement, lorsque la confidentialité est assurée) : un attaquant capable d'observer les données transitant par un lien n'est pas a même de déterminer quel volume de données est transféré entre deux hôtes particuliers ;

1' La confidentialité des données, si elle est demandée, s'entend a l'ensemble des champs, y compris les en-têtes du datagramme IP encapsulé dans le datagramme protégé par ESP.

Enfin, ESP et AH ne spécifient pas d'algorithmes de signature et/ou de chiffrement particuliers. Ceux-ci sont décrits séparément. Le tableau V.1 illustre les Fonctionnalités des modes tunnel et transport.

	Mode transport	Mode tunnel
AH	Authentifie l'information utile IP et certaines portions de l'en-tête IP et les en-têtes d'extension IPv6.	Authentifie le paquet IP tout entier plus certaines portions de l'en-tête externe et des en-têtes d'extension IPv6 externes.
ESP	Chiffre l'information utile IP et tout en-tête d'extension IPv6 suivant l'en-tête ESP.	Chiffre le paquet IP tout entier.
ESP avec authentification	Chiffre l'information utile IP et tout en-tête d'extension IPv6 suivant l'en-tête ESP. Authentifie l'information et utilise IP mais pas l'en-tête IP.	Chiffre le paquet IP tout entier. Authentifie le paquet IP.

V.3.3.3. Architecture

La RFC 2401 décrit le protocole IPSec au niveau le plus élevé. En particulier, elle indique ce qu'une implémentation est censée permettre de configurer en termes de politique de sécurité (c'est-à-dire quels échanges IP doivent être protégés par IPSec et le cas échéant, quel(s) protocole(s) utiliser). Sur chaque système capable d'utiliser IPSec, doit être présente une SPD (Security Policy Data base), dont la forme précise est laissée au choix de l'implémentation, et qui permet de préciser la politique de sécurité à appliquer au système. Chaque entrée de cette

base de données est identifiée par un SPI (Security Parameter Index) unique (32 bits). Une communication protégée a l'aide d'IPSec est appelée une SA (Security Association). Une SA repose sur une unique application de AH ou sur une unique application de ESP. Ceci n'exclut pas l'usage simultané de AH et de ESP entre deux systèmes, ou par exemple l'encapsulation des datagrammes AH dans d'autres datagrammes AH, mais plusieurs SA devront alors être activées entre les deux systèmes. En outre, une SA est unidirectionnelle. La protection d'une communication ayant lieu dans les deux sens nécessitera donc l'activation de deux SA. Chaque SA est identifiée de manière unique par un SPI, une adresse IP de destination (éventuellement adresse des broadcast ou de multicast) et un protocole (AH ou ESP). Les SA actives sont regroupées dans une SAD (Security Association Data base). La SPD est consultée pendant le traitement de tout datagramme IP, entrant ou sortant, y compris les datagrammes non IPSec. Pour chaque datagramme, trois comportements sont envisageables : le rejeter, l'accepter sans traitement IPSec, ou appliquer IPSec. Dans le troisième cas, la SPD précise en outre quels traitements IPSec appliquer (ESP, AH, mode tunnel ou transport, quel(s) algorithme(s) de signature et/ou de chiffrement utiliser). Les plus importants de ces termes sont les suivantes :

1' SPD Base de données définissant la politique de sécurité ; V' SA Une entrée de la SPD ;

Les règles de la SPD doivent pouvoir, si l'administrateur du système le souhaite, dépendre des paramètres suivants :

1' Nom d'utilisateur complet, (ce paramètre n'est toutefois pas obligatoire sur certains types d'implémentation) ;

1' Importance des données (ce paramètre n'est toutefois pas obligatoire sur certains types d'implémentation) ;

1' Ports source et destination (UDP et TCP seulement, le support de ce paramètre est facultatif).

Certains paramètres peuvent être illisibles a cause d'un éventuel chiffrement ESP au moment où ils sont traités, auquel cas la valeur de la SPD les concernant peut le préciser. Il s'agit de :

( L'identité de l'utilisateur ; 1' Le protocole de transport ; 1' Les ports source et destination.

Il est donc possible de spécifier une politique de sécurité relativement fine et détaillée. Cependant, une politique commune pour le trafic vers un ensemble des systèmes, permet une meilleure protection contre l'analyse de trafic qu'une politique extrêmement détaillée, comprenant de nombreux paramètres propres à chaque système particulier. Enfin, si l'implémentation permet aux applications de préciser elles-mêmes a quelle partie du trafic appliquer IPSec et comment, l'administrateur doit pouvoir les empêcher de contourner la politique par défaut.

Etude des protocoles de sécurité dans le réseau internet

V.3.3.2.2. ESP (Encapsulating Security Payload)

V.3.3.3. Architecture