III.2. INTEGRATION D'ISAKMP DANS SSL/TLS 7
III.2.1. Contraintes de base
Après la définition des principales motivations
de notre architecture, nous citons trois contraintes inhérentes à
sa conception globale. Les trois conditions pour réaliser un
déploiement simple et efficace d'ISAKMP avec SSL/TLS sont :
1. Utilisation des échanges et des blocs standards
ISAKMP afin de faciliter le déploiement de notre architecture et
afin de minimiser les tâches de développement de nouveaux blocs ou
échanges ISAKMP, nous avons essayé d'utiliser les blocs et les
échanges ISAKMP existants. Avec SSL/TLS, nous nous intéressons
surtout a l'échange de protection d'identité pour établir
la première association de sécurité ISAKMP. Nous nous
s'intéressons également a l'échange Quick Mode de
Oakley pour établir la deuxième association de
sécurité propre à SSL/TLS ;
2. Transparence par rapport à la couche Record de
SSL/TLS Puisque le changement dans SSL/TLS est au niveau Handshake, les
résultats d'échange (clé de chiffrement,
d'authentification, etc.) doivent être transparents au protocole Record
de SSL/TLS. C'est-à-dire, le mécanisme de dérivation des
clés à partir de la clé matérielle
générée avec ISAKMP doit ressembler à celui
utilisé par le protocole Handshake de SSL/TLS ;
3. Interopérabilité avec le protocole
SSL/TLS existant. En plus de l'interopérabilité avec le
protocole Record de SSL/TLS, notre approche doit permettre à des clients
SSL/TLS qui supportent notre proposition et à des serveurs qui ne la
supportent pas de se communiquer et vice versa.
III.2.2. Architecture
ISAKMP est un protocole de couche application placé
au-dessus de la couche transport. Selon la spécification de ce
protocole, il doit offrir ses services au dessus du protocole de transport UDP
mais il peut être utilisé directement au-dessus d'IP. Actuellement
et avec IKEv1, l'IANA lui a attribué le port 500 d'UDP. La figure III.1
illustre l'intégration d'ISAKMP dans SSL/TLS.
Fig. III.1 Intégration d'ISAKMP dans SSL/TLS
Avec SSL/TLS, ISAKMP peut fonctionner toujours sur le port 500
d'UDP. En effet, a la fin des deux phases ISAKMP, chaque protocole de
sécurité doit chiffrer et/ou authentifier son propre tunnel
indépendamment du protocole ISAKMP.
La figure III.2 illustre l'établissement de
différentes sessions pour ISAKMP et SSL/TLS.
Fig. III.2. Etablissement de différentes sessions
pour ISAKMP et SSL/TLS
Les quatre étapes nécessaires pour établir
une session SSL/TLS avec ISAKMP sont les suivantes :
1. Négociation d'ISAKMP SA. Durant la
première phase, un ensemble d'attributs relatifs à la
sécurité est négocié. Les identités des
tiers sont authentifiées et les clés sont
générées. Ces éléments constituent une
première association de sécurité que nous appelons ISAKMP
SA ;
2. Négociation de TLS SA. La seconde phase
permet de négocier les paramètres de sécurité
relatifs à une SA (Security Associations) pour le compte d'un protocole
de sécurité donné. Dans notre cas, c'est le protocole
SSL/TLS. Les échanges de cette phase sont sécurisés
(confidentialité, authenticité, etc.) grâce a l'association
de sécurité déjà établie. Celle-ci peut
être utilisée pour négocier plusieurs SA « fils »
destinées à d'autres mécanismes de sécurité
définis a travers des domaines d'interprétations (DOI) ;
3. Ouverture d'une session TCP. A ce point, ISAKMP a
établi tous les paramètres de sécurité (algorithme
de chiffrement, clés session, etc.) nécessaires au chiffrement de
tout type de données (page Web, fichier, vidéo, etc.) avec la
couche Record de SSL/TLS. Maintenant, c'est a l'application qui
souhaite utiliser SSL/TLS d'établir une première connexion TCP
vers le port défini par chaque application ;
4. Echange des messages CCS et des données
chiffrées. Dans la dernière partie (étape 4 et 5),
les clés de chiffrement sont activées avec le module CCS
(ChangeCipherSpec) de SSL/TLS. Les messages CCS qui ne font
pas partie du protocole Handshake, sont envoyés au début du
premier échange de données chiffrées. De plus, afin de
protéger ces messages contre l'attaque homme du milieu, nous proposons
de les ajouter dans le premier échange chiffré des
données.
| 
