V.3.4.2. Architecture
Si le DOI IPSec précise le contenu des blocs ISAKMP
dans le cadre d'IPSec, IKE en revanche, utilise ISAKMP pour construire un
protocole pratique. Il utilise certains des modes définis par Oakley et
emprunte à SKEME son utilisation du chiffrement a clé publique
pour l'authentification et sa méthode de changement de clef rapide par
échanges d'aléas.
Bien que ce nom insiste sur le rôle d'échange de
clés, IKE se charge en réalité de la gestion
(négociation, mise à jour, suppression) de tous les
paramètres relatifs à la sécurisation des échanges.
Contrairement aux mécanismes AH (Authentification Header) et ESP
(Encapsulating Security Payload) qui agissent directement sur les
données à sécuriser, IKE est un protocole de plus haut
niveau, dont le rôle est l'ouverture et la gestion d'un pseudo connexion
au-dessus de tout protocole de transport ou sur IP directement (les
réalisations doivent cependant supporter au moins le protocole UDP,
l'IANA a attribué le port 500 a ISAKMP).
IKE inclut, au début de la négociation, une
authentification mutuelle des tiers communicants qui peut se baser soit sur un
secret partagé préalablement, soit sur des clés
publiques.
L'échange des clés publiques utilisées
par IKE peut se faire soit manuellement, soit directement dans le cadre d'IKE
par un échange de certificats en ligne, ou encore par le biais d'une
infrastructure à clés publiques (Public Key Infrastructure, PKI)
extérieure. DOI définit la syntaxe des paramètres, les
types d'échanges et les conventions de nommage relatifs a l'emploi
d'ISAKMP dans un cadre particulier. Un
identifiant (DOI identifier) est par conséquent
utilisé pour interpréter et synthétiser la charge utile
des messages ISAKMP dans le contexte d'un DOI donné. Par exemple, le
protocole IPSec a le numéro 1 comme identifiant pour son DOI.
L'utilisation d'ISAKMP avec un nouveau protocole (tel que le cas que nous
proposons pour SSL/TLS) exige la définition d'un nouveau DOI propre a ce
protocole. La figure V.7 illustre la présentation symbolique du domaine
d'interprétation d'ISAKMP IPSec.
Fig. V.7. Présentation symbolique du domaine
d'interprétation d'ISAKMP IPSec
V.3.4.3. Echanges ISAKMP/IKEv1
ISAKMP comprend deux phases de communication qui permettent
une séparation claire de la négociation des SA pour un protocole
spécifique et la protection du trafic ISAKMP.
La première phase entame la négociation d'une
association de sécurité relative au protocole ISAKMP. Une fois
les paramètres partagés et l'échange authentifié,
la S ISAKMP est établie. Celle-ci définit la manière dont
deux entités ISAKMP vont sécuriser leurs échanges
ultérieurs. Ceci constitue une première « association de
sécurité » connue sous le nom de SA ISAKMP.
La deuxième phase permet la négociation des
nouveaux paramètres de sécurité liés à un
autre protocole, comme AH (Authentication Header) et ESP (Encapsulating
Security Payload). Les échanges de cette phase sont
protégés par l'association de sécurité
établie dans la phase 1 (SA ISAKMP).
La figure V.8 illustre les phases d'IKEv1.
Fig. V.8. Phases d'IKEv1
Pour les échanges ISAKMP, le RFC 2408 a défini
cinq types d'échanges pour la phase 1 : Base Exchange, Identity
Protection Exchange, Authentication Only Exchange, Aggressive Exchange et
Informational Exchange. Pour la phase 2, la définition des types
d'échange est laissée au protocole qui utilise ISAKMP pour
satisfaire ces propres besoins en termes de gestion des clés et de
sécurité. Dans le cadre du protocole IKE, il utilise une instance
de l'échange Identity Protection Exchange (ou main mode) et
Aggressive Exchange comme des échanges de la phase 1 de IKEv1.
L'échange Aggressive Exchange (ou quick mode) est aussi
défini comme un échange de la phase 2 de IKEv1 avec quelques
messages optionnels.
| 
