WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

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


par Fils NZALANKUMBU DIALEMBA
Institut supérieur de techniques appliquées Kinshasa - Ingénieur en informatique appliquée 2007
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

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.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy