III.2.3. Négociation des associations de
sécurité
Nous décrivons un ordre de messages
échangés pendant les deux phases ISAKMP (étape 1 et 2 du
paragraphe précédent) afin de fournir un exemple concret de
l'intégration d'ISAKMP dans SSL/TLS. Les deux phases possèdent
les caractéristiques suivantes :
1' Dans la première phase, les deux communicateurs
(client et serveur SSL/TLS) initient l'échange de protection
d'identité. Cet échange est basé sur une authentification
mutuelle forte avec des certificats X.509 obtenus a partir d'une
autorité de certification valide. Pour le client, son authentification
est plutôt liée au matériel qu'il utilise. Le
résultat de cet échange est la génération d'une
clé secrète (SKEYID) et un ensemble des clés
dérivées (SKEYID_d, SKEYID_a, SKEYID_e) servant à
la génération de
nouvelles clés, a l'authentification et au chiffrement des
messages de la phase 2 ;
1' Dans la deuxième phase, les deux communicateurs
établissent une association de sécurité pour SSL/TLS.
L'échange que nous proposons diffère courtement de
l'échange Quick Mode d'Oakley. Nous l'appelons pour cela «
TLS Quick Mode ». Cet échange permet aux deux
entités :
1. de renégocier leur méthode
d'authentification. Durant le deuxième échange, les deux
entités (surtout le client) peuvent présenter de nouvelles
identités, négocier leurs méthodes d'authentification et
préciser l'adresse d'un serveur SSL/TLS (serveur virtuel ou réel)
contenant les ressources demandées. Pour le serveur, sa
réauthentification est inutile sauf a la suite d'une demande de
certificat envoyée par le client. Ceci dans le cas oü le serveur
demandé n'était pas authentifié durant la première
phase ;
La figure III.3 illustre la Négociation des associations
de sécurité avec plusieurs serveurs virtuels.
Fig. III.3. Négociation des associations de
sécurité avec plusieurs serveurs virtuels
2. de permettre au client SSL/TLS de rester anonyme.
Puisque dans la plupart des scénarios SSL/TLS le client est
anonyme, nous avons introduit une nouvelle méthode d'authentification
« anonyme » pour les clients. Elle requiert aucune
modification ni au niveau des blocs ISAKMP, ni au niveau du mécanisme de
génération des clés, mais seulement l'ajout d'un nouveau
attribut «anonymous_client» dans le DOI de SSL/TLS.
III.2.3.1. Négociation d'ISAKMP SA
Durant cette phase, les deux communicateurs établissent
la première association de sécurité appelée ISAKMP
SA. Puisque nous utilisons l'échange de protection d'identité,
les deux entités échangent six messages pour négocier
leur
stratégie de sécurité et pour
protéger leur identité. Tous les échanges commencent avec
un en-tête ISAKMP (HDR) suivi par un nombre variable de
blocs.
| 
