II.4. Le protocole AH (Authentification Header)
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 rejet se fait grâce à un
numéro de séquence.
II.5 Le Protocole ESP (Encapsulating Security
Payload)
Le protocoLe ESP peut assurer au choix, un ou pLusieurs des
services
suivants :
ConfidentiaLité (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
contre Le rejeu. La confidentiaLité peut être
séLectionnée indépendamment des autres services, mais son
utiLisation sans intégrité/authentification (directement dans Esp
ou avec AH) rend Le trafic vuLnérabLe à certains types d'attaques
actives qui pourraient affaibLir Le service de confidentiaLité.
Le champ bourrage peut être nécessaire pour Les
aLgorithmes de chiffrement par bLocs ou pour aLigner Le texte chiffré
sur une Limite de 4 octets. Les données d'authentification ne sont
présentes que si ce service a été
séLectionné. Voyons maintenant comment est appLiquée La
confidentiaLité dans ESP.
Du côté de l'expéditeur
Ce protocoLe encapsuLe, dans Le champ "charge utiLe" de ESP,
Les données transportées par Le datagramme originaL et
éventueLLement L'en-tête IP (mode tunneL) ; Ajoute si
nécessaire un bourrage; Chiffre Le résuLtat (données,
bourrage, champs Longueur et en-tête suivant).
Ajoute éventueLLement des données de
synchronisation cryptographiques (vecteur d'initiaLisation) au début du
champ "charge utiLe".
II.6. La gestion des clefs pour IPSec : Isakmp et
Ike
Les protocoLes sécurisés
présentés dans Les paragraphes précédents ont
recours à des aLgorithmes cryptographiques et ont donc besoin de cLefs.
Un des probLèmes fondamentaux d'utiLisation de La cryptographie est La
gestion de ces cLefs. Le terme "gestion" recouvre La génération,
La distribution, Le stockage et La suppression des cLefs. IKE (Internet Key
Exchange) est un système déveLoppé spécifiquement
pour IPSec qui vise à fournir des mécanismes d'authentification
et
d'échange de cLef adaptés à L'ensembLe
des situations qui peuvent se présenter sur L'Internet. IL est
composé de pLusieurs éLéments : Le cadre
générique Isakmp, une partie des protocoLes OakLey et Skeme.
Lorsqu'iL est utiLisé pour IPSec, IKE est de pLus compLété
par un "domaine d'interprétation" pour IPSec.
| 
