(Internet Key Exchange) Configurer le Protocole de sécurité IKE (Internet Key Exchange) ccnp_cch

Sommaire  Introduction - Contenu  Présentation générale de IKE - Standards supportés - Liste de termes - Comportement IKE en mode "agressive"  Tâches de configuration de IKE - Valider ou dévalider IKE - S'assurer que les listes d'accès sont compatibles avec IKE - Création de politiques IKE - Configuration manuelle de clés RSA - Configuration de clés pré-partagées - Configuration du mode de configuration de IKE - Configuration de Tunnel Endpoint Discovery (TED) - Effacement des connexions IKE - Résolution de problèmes IKE  Exemples de configuration de IKE ccnp_cch

Présentation générale de IKE Introduction Ce document décrit comment configurer le protocole IKE (Internet Key Exchange). IKE est un protocole de gestion de clé standard qui est utilisé en conjonction avec le stan- dard IPSec. IPSec est une fonctionnalité de sécurité IP qui fournit une authentification et un cryptage robustes des paquets IP. IPSec peut être configuré sans IKE mais IKE améliore IPSec en fournissant des fonc- tionnalités additionnelles, de la flexibilité et de la facilité de configuration pour le stan- dard IPSec. IKE est un protocole hybride qui implémente l'échange de clé Oakley et l'échange de clé Skeme dans le protocole ISAKMP (Internet Security Associations and Key Management Protocol). (ISAKMP, Oakley et Skeme sont des protocoles de sécurité implémentés par IKE). Contenu Ce document contient les sections suivantes:  Présentation générale de IKE  Tâches de configuration de IKE  Exemples de configuration de IKE Présentation générale de IKE IKE négocie automatiquement les associations de sécurité IPSEC (SAs) et permet des communications IPSec sécurisées sans préconfiguration manuelle coûteuse en temps. Spécifiquement IKE à les avantages suivants:  Elimine le besoin de spécifier manuellement tous les paramètres de sécurité IPSec dans les crypto maps aux deux extrémités.  Vous permet de spécifier une durée de vie pour les associations de sécurité IPSec.  Permet de changer les clés de cryptage pendant les sessions IPSec.  Permet à IPSec de fournir des services "anti-replay".  Permet le support d'une autorité de certification (CA) pour une implémentation IPSec évolutive et administrable.  Permet une authentification dynamique des extrémités. Cette section comprend les chapitres suivants:  Standards supportés  Liste de termes  Comportement IKE mode "Aggressive" ccnp_cch

ccnp_cch Standards supportés Cisco implémente les standards suivants:  IPSec - IP Security protocol. IPSec est un cadre de standards ouverts qui fournit la confidentialité des données, l'intégrité des données entre deux extrémités. IPSec fournit ces services de sécurité à la couche IP, il utilise IKE pour gérer la négocia- tion des protocoles et algorithmes basée sur une politique locale et pour générer les clés de cryptage et d'authentification utilisées avec IPSec. IPSec peut être utilisé pour protéger un ou plusieurs flux de données entre une paire de hosts entre une paire de passerelles de sécurité ou entre un host et une passerelle de sécurité.  IKE - Internet Key Exchange. Protocole hybride qui implémente les échanges de clés Oakley et Skeme dans le cadre de ISAKMP. Tandis que IKE peut être utilisé avec d'autres protocoles, son implémentation initiale s'est faite avec le protocole IPSec. IKE fournit l'authentification des extrémités IPSec, négocie les clés IPSec et négocie les associations de sécurité IPSec. IKE est implémenté par le RFC 2409, "The Internet Key Exchange".  ISAKMP - Internet Security Association and Key Management Protocol. Protocole cadre qui définit les formats des charges utiles, les mécanismes d'implémentation d'un protocole d'échange de clés et la négociation des associations de sécurité. ISAKMP est implémenté avec la dernière version de "Internet Security Association and Key Management Protocol (ISAKMP)" Internet Draft (RFC2408).  Oakley - Protocole d'échange de clés qui définit comment s'accorder sur un dispo- sitif de cryptage secret.  Skeme - Protocole d'échange de clés qui définit comment s'accorder sur un dispo- sitif de cryptage secret avec rafraîchissement rapide de clé. Les composantes technologiques implémentées pour être utilisées avec IKE sont:  DES - Data Encryption Standard (DES) est utilisé pour crypter les paquets de don- nées. IKE implémente le standard 56 bits DES-CBC avec IV explicite. CBC (Cypher Block Chaining) requiert un vecteur d'initialisation (IV) pour commencer le crypta- ge. Le vecteur d'initialisation (IV) est explicitement fournit dans le paquet IPSec. L'IOS Cisco implémente également le cryptage Triple-DES selon les versions logi- cielles disponibles pour une plateforme spécifique. Triple-DES (3DES) est une for- me robuste de cryptage qui permet à des informations sensibles d'être transmises sur des réseaux non sécurisés. Il permet à des clients, en particulier dans le do- maine de la finance, d'utiliser un cryptage de couche réseau. Note: Les images de l'IOS Cisco avec un cryptage robuste (incluant mais non limité au cryptage de données 56 bits) sont sujettes aux contrôle d'exportation du gouver- nement des Etats-Unis et ont une distribution limitée. Les images devant être ins- tallées hors des Etats-Unis ont besoin d'une licence. Les demandes des clients peu- vent refusées ou temporisées à cause de la réglementation des Etats-Unis. ccnp_cch

 Diffie-Hellman - Protocole de cryptographie à clé publique qui permet à deux par- ties d'établir un secret partagé sur un canal de communication non sécurisé. Le pro- tocole Diffie-Hellman est utilisé dans IKE pour établir les sessions de clés. Les grou- pes Diffie-Hellman 768 bits et 1024 bits sont supportés.  MD5 (Variante HMAC) - MD5 (Message Digest 5) est un algorithme de hachage uti- lisé pour authentifier les paquets de données. HMAC est une variante qui fournit un niveau hachage supplémentaire.  SHA (variante HMAC) - SHA (Secure Hash Algorithm) est un algorithme de hachage utilisé pour authentifier les paquets de données. HMAC est une variante qui fournit un niveau hachage supplémentaire.  Signatures RSA et nonces RSA cryptées - RSA est un système de cryptage à clés publiques développé par Ron Rivest, Adi Shamir et Leonard Adleman. RSA fournit des signatures de non répudiation tandis que les nonces RSA cryptées fournissent la répudiation. IKE interopère avec le standard suivant:  Certificats X509v3 - Utilisés avec le protocole IKE quand l'authentification requiert des clés publiques. Le support de certificat permet au réseau protégé d'évoluer en fournissant l'équivalent d'un ID de carte numérique à chaque équipement. Quand deux équipements désirent communiquer, ils échangent des certificats numériques pour prouver leur identité (retirant ainsi la nécessité d'échanger manuellement les clés publiques avec chaque extrémité ou de spécifier manuellement une clé parta- gée à chaque extrémité. Liste de termes  anti-replay - Un service de sécurité dans lequel le receveur peut rejeter des paquets anciens ou dupliqués pour se protéger contre des attaques de ce type. IPSec fournit des services optionnels d'anti-replay par l'utilisation d'un numéro de séquence com- biné avec l'authentification.  authentification des données - Comprend ces deux concepts: - Intégrité des données (vérifie que les données n'ont pas été altérées) - Authentification de l'origine des données (vérifie que les données sont bien trans- mises par un émetteur reconnu) L'authentification des données peut faire référence soit à l'intégrité seule ou aux deux concepts (bien que l'authentification de l'origine des données dépend de l'intégrité des données).  peer - Dans le contexte de ce document, un peer fait référence à un routeur ou à tout autre équipement qui participe à IPSec et à IKE. ccnp_cch

 perfect forward secrecy (PFS) - Une caractéristique de cryptographie associée avec une valeur dérivée du secret partagé. Avec PFS si une clé est compromise, les clés précédentes est suivantes ne sont pas compromises car les clés suivantes ne sont pas dérivées des clés précédentes.  répudiation - Une qualité qui évite qu'une tierce personne prouve qu'une communi- cation entre deux autres parties a eu lieu. La non-répudiation est la qualité oppo- sée; une tierce partie peut prouver qu'une communication entre deux autres par- ties a eu lieu. La non répudiation est souhaitable si vous voulez garder trace des communications et prouver qu'elles ont eu lieu.  Security Association (SA) - Une association de sécurité (SA) décrit comment deux ou plusieurs entités utiliseront les services de sécurité pour communiquer. Par exemple, une SA IPSec définit l'algorithme de cryptage (si utilisé), l'algorithme d'au- thentification et la clé de session partagée à utiliser pendant la connexion IPSec. IPSec et IKE requièrent et utilisent les SAs pour identifier les paramètres de leurs connexions. IKE peut négocier et établir sa propre SA. La SA IPSec est établie soit par IKE soit par configuration manuelle de l'utilisateur. Comportement IKE en mode "Aggressive" Ce chapitre décrit le comportement de IKE en mode "Aggressive" quand on utilise le logiciel IOS Cisco. IKE a deux phases de négociation de clés: phase 1 et phase 2. La phase 1 négocie une association de sécurité (clé) entre deux extrémités. La clé négociée dans la phase 1 permet à deux extrémités IKE de communiquer de manière sécurisée dans la phase 2. Pendant la négociation phase 2, IKE établit les clés (associations de sécurité) pour d'autres applications comme IPSec. La négociation phase 1 peut se produire en utilisant un des deux modes: le mode prin- cipal et le mode agressif (aggressive). Le mode principal tente de protéger toutes les in- formations pendant la négociation ce qui signifie qu'aucune information n'est disponi- ble pour un attaquant éventuel. Quand le mode principal est utilisé, les identités des deux extrémités sont cachées. Tandis que ce mode de fonctionnement est plus sécuri- sé, il est plus coûteux en terme du temps qu'il prend pour exécuter la négociation. Le mode "Aggressive" prend moins de temps pour négocier les clés entre les extrémités; toutefois il abandonne un peu de la sécurité fournie par le mode principal. Par exem- ple les identités des deux parties qui tentent d'établir une association de sécurité sont exposées à des écoutes. Les deux modes répondent à différents besoins et ont des avantages différents. Le mo- de principal est plus lent que le mode "Aggressive" mais le mode principal est plus sé- curisé et plus flexible car il peut offrir à une extrémité IKE plus de propositions de sé- curité que le mode "Aggressive". Le mode "Aggressive" est moins flexible et moins sécu- risé mais beaucoup plus rapide. Dans l'IOS Cisco, les deux modes ne sont pas configurables. L'action par défaut pour l'authentification IKE (rsa-sig, rsa-enc ou pr-partagée) est d'initier le mode principal; toutefois dans le cas où il n'y a pas d'information correspondante pour initier le mode ccnp_cch

principal pour l'authentification et qu'il y a une clé pré-partagée associé au nom de host de l'extrémité, l'IOS Cisco peut initier le mode "Agressive". L'IOS Cisco répondra en mode "Aggressive" à une extrémité IKE qui initie le mode "Aggressive". Tâches de configuration de IKE Pour configurer IKE, exécutez ces tâches dans les sections suivants. les tâches dans les trois premières sections sont requises; le reste des tâches peut être optionnel selon les paramètres configurés.  Valider ou dévalider IKE  S'assurer que les listes d'accès sont compatibles avec IKE  Création de politiques IKE  Configuration manuelle de clés RSA  Configuration de clés pré-partagées  Configuration du mode de configuration de IKE  Configuration de Tunnel Endpoint Discovery (TED)  Effacement des connexions IKE  Résolution de problèmes IKE Valider ou dévalider IKE IKE est validé par défaut. IKE n'a pas besoin d'être validé pour chaque interface car il est validé globalement pour toutes les interfaces du routeur. Si vous ne voulez pas que IKE soit utilisé avec votre implémentation IPSec, vous pou- vez le dévalider dans toutes les extrémités IPSec. Si vous dévalidez IKE, vous devez faire ces concessions aux extrémités:  Vous devez spécifier manuellement toutes les associations de sécurité IPSec dans les crypto maps à toutes les extrémités.  Les associations de sécurité des extrémités pour une session IPSec donnée n'expi- rent jamais.  Pendant les sessions entre extrémités IPSec les clés de cryptage ne changent jamais.  Les services "anti-replay" ne seront pas disponibles entre les extrémités.  Le support d'autorité de certification (CA) ne peut pas être utilisée. ccnp_cch

S'assurer que les listes d'accès sont compatibles avec IKE Pour valider ou dévalider IKE, utilisez une des commandes suivantes en mode de con- figuration global. Commande But Routeur(config)# no crypto isakmp enable Valide IKE. Routeur(config)# crypto isakmp enable Dévalide IKE. Si vous dévalidez IKE, vous pouvez passer le reste des tâches et configurer IPSec direc- tement. S'assurer que les listes d'accès sont compatibles avec IKE La négociation IKE utilise le port UDP 500. Assurez-vous que vos listes d'accès sont configurées pour que le trafic du port UDP 500 ne soit pas bloqué sur les interfaces utilisées par IKE. Dans certains cas, vous aurez besoin de rajouter une instruction à vos listes d'accès pour permettre explicitement le trafic UDP port 500. Création de politiques IKE Vous devez utiliser des politiques IKE à chaque extrémité. Une politique IKE définit une combinaison de paramètres de sécurité devant être utilisés pendant la négociation IKE. Pour créer une politique IKE, suivez les directives des sections suivantes:  Pourquoi avez-vous besoin de créer ces politiques?  Quels sont les paramètres que vous définissez dans une politique?  Comment les extrémités IKE s'accordent sur une politique?  Quelles sont les valeurs que vous devez choisir pour chaque paramètre?  Création de politiques  Configuration additionnelle requise pour les politiques IKE Pourquoi avez-vous besoin de créer ces politiques? Les négociation IKE doivent être protégées, aussi chaque négociation IKE débute par l'agrément d'une politique IKE commune (partagée) par les extrémités. Cette politique définit quels paramètres de sécurité seront utilisés pour protéger les négociations IKE qui suivent et signifie comment les extrémités doivent être authentifiées. Après que les deux extrémités se soient accordées sur la politique, les paramètres de sécurité de la politique sont identifiés par une association de sécurité établie à chaque extrémité et ces associations de sécurité s'appliquent à tout le trafic IKE pendant la négociation. ccnp_cch

Vous pouvez créer plusieurs politiques avec des priorités à chaque extrémité pour as- surer que au moins une politique correspondra avec une politique de l'extrémité dis- tante. Quels sont les paramètres que vous définissez dans une politique ? Il y a cinq paramètres à définir dans chaque politique IKE: Paramètre Valeurs acceptées Mot clé Valeur par défaut Algorithme de cryptage 56-bit DES-CBC 168-bit DES des 3des hash algorithm SHA-1 (HMAC variant) MD5 (HMAC variant) sha md5 SHA-1 Méthode d'authentification RSA signatures RSA encrypted nonces pre-shared keys rsa-sig rsa-encr pre-share Signatures RSA Groupe Diffie-Hellman 768-bit Diffie-Hellman ou 1024-bit Diffie-Hellman 1 2 768-bit Diffie-Hellman Durée de vie des associations de sécurité Vous pouvez spécifier un nombre quelconque de secondes. __ 86400 secondes (1 jour) Ces paramètres s'appliquent aux négociations IKE quand les associations de sécurité IKE sont établies. Comment les extrémités IKE s'accordent sur une politique ? Quand la négociation IKE débute, IKE recherche une politique qui est la même aux deux extrémités. L'extrémité qui initie la négociation transmet toutes ses politiques vers l'extrémité distante et l'extrémité distante essaie de trouver une politique qui cor- respond. l'extrémité distante cherche une correspondance en comparant sa politique de priorité la plus élevée avec les politiques reçues de l'autre extrémité. L'extrémité dis- tante vérifie chacune de ses politiques ( de priorité la plus élevée vers la plus basse) jusqu'à ce qu'elle trouve une correspondance. Une correspondance est trouvée quand deux politiques à chacune des extrémités con- tiennent les mêmes paramètres de cryptage, de hachage, d'authentification et Diffie- Hellman et lorsque la politique de l'extrémité distante spécifie une durée de vie égale ou inférieure à la durée de vie de la politique en cours de comparaison. (Si les durées de vie sont inégales, la durée de vie la plus courte - venant de la politique de l'extrémi- té distante - sera utilisée). Si aucune correspondance acceptable n'est trouvée, IKE refuse la négociation et IPSec ne sera pas établi. Si une correspondance est trouvée, IKE termine la négociation et les associations de sécurité IPSec seront créées. ccnp_cch

Note: Selon la méthode d'authentification spécifiée dans une politique, une configura- tion additionnelle peut être requise (décrite dans le paragraphe Configuration addition- nelle requise pour les politiques IKE). Si une politique à une extrémité n'a pas la confi- guration complémentaire requise, l'extrémité ne soumettra pas cette politique quand elle tentera de faire la correspondance avec une politique de l'extrémité distante. Quelles sont les valeurs que vous devez choisir pour chaque paramètre? Vous pouvez sélectionner certaines valeurs pour chaque paramètres, selon le standard IKE. Mais pourquoi choisir une valeur plutôt qu'une autre ? Si vous interopérer avec qui supporte uniquement une de ces valeurs pour un paramè- tre, votre choix est limité à la valeur supportée par l'autre équipement. A côté de cela, il y a souvent un compromis entre sécurité et performance et beaucoup de ces valeurs de paramètres représentent un tel compromis. Vous devez évaluer le niveau des ris- ques de sécurité de votre réseau et votre tolérance au sujet de ces risques. Ces indica- tions pourront vous aider à sélectionner la valeur à spécifier pour chaque paramètre:  L'algorithme de cryptage a deux options : 56 bits DES-CBC et 168 bits DES.  L'algorithme de hachage a deux options : SHA-1 et MD5. MD5 a un "digest" plus petit et il est considéré pour être légèrement plus rapide que SHA-1. Une attaque réussie de MD5 (mais très complexe) a été démontrée. La vari- ante HMAC utilisée par IKE empêche cette attaque.  La méthode d'authentification a trois options: signatures RSA, nonces RSA cryptées et clés pré-partagées. - Les signatures RSA fournissent la non-répudiation pour la négociation IKE (vous pouvez prouvez à une tierce partie que vous avez réellement eu une négociation KE avec l'extrémité distante). Les signatures RSA vous permettent d'utiliser une autorité de certificat (CA). L'uti- lisation d'une CA peut grandement améliorer l'évolutivité et l'administration de vo- tre réseau IPSec. De plus l'authentification basée sur les signatures RSA utilise uniquement deux opérations de clés publiques alors que le cryptage RSA utilise quatre opérations de clés, ce qui le rend plus coûteux en termes de performance globale. Vous pouvez également échanger les clés publiques manuellement (voir la section "Configuration Manuelle des clés RSA"). - Les nonces RSA cryptées fournissent la répudiation pour la négociation IKE (vous ne pouvez pas prouver à une tierce partie que vous avez eu une négociation IKE avec l'extrémité distante). Les nonces RSA cryptées requièrent que les extrémités possèdent les clés publi- ques l'une de l'autre et n'utilisent pas d'autorité de certificat. Au lieu de cela il y a deux moyens pour les extrémités pour obtenir la clé publique l'une de l'autre: ccnp_cch

1) Pendant la configuration vous devez configurer les clés RSA manuellement (comme cela est décrit dans la section "Configurer les clés RSA manuellement") 2) Si votre extrémité locale a déjà utilisé des signatures RSA avec des certificats lors de négociation IKE réussie avec l'extrémité distante, votre extrémité locale possède déjà la clé publique de l'extrémité distante. ( Les clés publiques des extrémités sont échangées lors de négociations IKE basées sur les signatures RSA si les certificats sont utilisés). - Les clés pré-partagées sont d'un usage mal aisé si votre réseau est grand et elles ne sont pas adaptées à l'évolution d'un réseau. Cependant celles-ci ne requièrent pas d'autorité de certificat comme les signatures RSA et peuvent être plus faciles à mettre en œuvre dans un petit réseau avec moins de 10 machines. Les signatu- res RSA peuvent être considérées comme plus sécurisantes que l'authentification par clés pré-partagées.  Le groupe Diffie-Hellman a deux options: 768 bits ou 1024 bits. L'option Diffie-Hellman 1024 bits est plus difficile à "craquer" mais demande plus de ressources CPU.  La durée de vie des associations de sécurité peut avoir une valeur quelconque. En règle générale, plus la durée de vie est courte (jusqu'à un certain point) plus les négociations IKE sont sécurisées. Cependant avec des durées de vie plus longues, les associations de sécurité IPSec pourront être établies plus vite. Pour plus d'infor- mation sur ce paramètre et la manière de l'utiliser, voir la description de la com- mande lifetime (politique IKE). Création de politiques Vous pouvez créer plusieurs politiques IKE chacune avec une combinaison différente des valeurs de paramètres. Pour chaque politique que vous créez, vous affectez une priorité unique (1 à 10000 avec 1 pour priorité la plus élevée). Vous pouvez configurer plusieurs politiques sur chaque extrémité mais au moins une de ces politiques doit contenir exactement les mêmes valeurs de paramètres pour le cryptage, le hachage, l'authentification et Diffie-Hellman qu'une des politiques de l'ex- trémité distante. (Le paramètre durée de vie n'a pas besoin d'être le même; voir les détails sur "Comment les extrémités IKE s'accordent sur une politique?"). Si vous ne configurez pas de politiques, votre routeur utilisera la politique par défaut qui a toujours la priorité la plus basse et qui contient la valeur par défaut de chaque paramètre. Pour configurer une politique, utilisez les commandes suivantes en mode de configu- ration global. ccnp_cch

Commande But Routeur(config)# crypto isakmp policy priority Identifie la politique à créer. (Chaque politique est identifiée de manière unique par le numéro de priorité que vous lui affectez. (Cette commande vous place en mode de confi-guration isakmp.) Routeur(config-isakmp)# encryption {des | 3des} Spécifie l'algorithme de cryptage. Routeur(config-isakmp)# hash {sha | md5} Spécifie l'algorithme de hachage. Routeur(config-isakmp)# authentication {rsa-sig | rsa-encr | pre-share} Spécifie la méthode d'authentification. Routeur(config-isakmp)# group {1 | 2} Spécifie le groupe Diffie-Hellman. Routeur(config-isakmp)# lifetime seconds Spécifie la durée de vie des associations de sé- curité. Routeur(config-isakmp)# exit Sortie du mode de configuration isakmp. Routeur(config)# exit Sortie du mode de configuration. Routeur# show crypto isakmp policy (Optionnel) Affiche toutes les politiques IKE existantes. Si vous ne spécifiez pas de valeur pour un paramètre, la valeur par défaut est affectée. Note: La politique par défaut et les valeurs par défaut pour les politiques configurées ne sont pas affichées dans la configuration quand vous entrez la commande show running-config. Pour voir la politique par défaut et les valeurs par défaut dans la con- figuration des politiques, utilisez la commande show crypto isakmp policy. Configuration additionnelle requise pour les politiques IKE Selon la méthode d'authentification que vous spécifiez dans vos politiques IKE, vous aurez besoin de faire un configuration additionnelle avant que IKE et IPSec puissent utiliser les politiques IKE. Chaque méthode d'authentification requiert une configuration d'accompagnement comme suit:  Méthode avec signature RSA Si vous spécifiez des signatures RSA comme méthode d'authentification dans une politique, vous pouvez configurer les extrémités pour qu'elles obtiennent des certifi- cats d'une autorité de certification (CA). (La CA doit bien sur être correctement con- figurée pour délivrer les certificats). Configurez ce support comme cela est décrit dans "Configuration de l'interopérabilité avec l'autorité de certification". Les certificats sont utilisés par chaque extrémité pour échanger les clés publiques de manière sécurisée. (Les signature RSA requièrent que chaque extrémité ait la clé publique de signature de l'extrémité distante). Quand les deux extrémités ont des l  ccnp_cch

certificats valides, elles échangeront automatiquement les clés publiques entre elles dans toute partie de négociation IKE dans laquelle les signatures RSA sont utilisées. Vous avez également l'option d'échanger les clés publiques manuellement, comme cela est décrit dans la section "Configuration manuelle de clé RSA".  Méthode nonces RSA cryptées Si vous spécifiez des nonces RSA cryptées comme méthode d'authentification dans un politique, vous aurez besoin de vous assurer que chaque extrémité a les clés pu- bliques de l'autre extrémité. Contrairement aux signatures RSA, la méthode des nonces cryptées ne peut pas uti- liser des certificats pour échanger des clés publiques. Au lieu de cela, vous devez vous assurer que les extrémités ont les clés publiques l'une de l'autre. - Configurez manuellement les clés RSA comme cela est décrit dans la section "Configuration manuelle de clés RSA". - Assurez-vous qu'un échange IKE utilisant des signatures RSA s'est déjà produit entre les extrémités. (les clés publiques des extrémités sont échangées pendant les négociations IKE basées sur les signatures si les certificats sont utilisés). Pour que cela se produise, spécifiez deux politiques: une politique de priorité éle- vée avec des nonces RSA cryptées et une politique de priorité basse avec des si- gnatures RSA. Quand les négociations IKE se produisent, les signatures RSA se- ront utilisées en premier car les extrémités n'ont pas encore les clés publiques l'une de l'autre. Par la suite les négociations IKE futures pourront utiliser les non- ces RSA cryptées car les clés publiques auront été changées. Bien sur cette alternative requiert que le support de l'autorité de certificat soit configuré.  Méthode d'authentification par clés pré-partagées Si vous spécifiez des clés pré-partagées comme méthode d'authentification dans une politique, vous devez configurer ces clés pré-partagées comme cela est décrit dans la section "Configuration de clés pré-partagées". Si le cryptage RSA est configuré et que le mode signature est négocié (et les certificats sont utilisés pour le mode signature), l'extrémité demandera les clés de signature et de cryptage. De base le routeur demandera autant de clés que celles configurées. Si le cryptage RSA n'est pas configuré, le routeur demandera un clé de signature. Configuration manuelle des clés RSA Configurez manuellement les clés RSA quand vous spécifiez les nonces RSA cryptées comme méthode d'authentification dans la politique IKE et que vous n'utilisez pas les certificats. ccnp_cch

Pour configurer manuellement les clés RSA, exécutez ces tâches à chaque extrémité IPSec qui utilise les nonces RSA cryptées dans une politique IKE.  Génération des clés RSA  Fixer l'identité ISAKMP  Spécification de toutes les clés publiques RSA des autres extrémités Génération des clés RSA Pour générer des clés RSA, utilisez les commandes suivantes en mode de configuration global. Commande But Routeur(config)# crypto key generate rsa [usage-keys] Génère les clés RSA. Routeur#show crypto key mypubkey rsa Affiche la clé publique RSA générée. N'oubliez pas de répéter ces tâches à chaque extrémité (sans le support de CA) qui utilise les nonces RSA cryptées dans la politique IKE. Fixer l'identité ISAKMP Vous devez fixer l'identité ISAKMP pour chaque extrémité qui utilise des clés pré-parta- gées dans une politique IKE. Quand deux extrémités utilisent IKE pour établir des associations de sécurité IPSec, chacune des extrémités transmet son identité à l'extrémité distante. Chaque extrémité transmet soin son nom de host soit son adresse IP selon la manière dont vous avez établi l'identité ISKMP du routeur. Par défaut, l'identité ISAKMP d'une extrémité est l'adresse IP. Si cela est approprié, vous pouvez changer l'identité pour que cela soit le nom de host. En règle générale, fixer les identités avec la même manière: soit toutes les extrémités doivent utiliser leur adresse IP soit elles doivent utiliser leur nom de host. Si quelques extrémités utilisent leur nom de host et d'autres utilisent leur adresse IP pour s'identifier entre elles, les négociations IKE peuvent échouer si l'identité d'une extrémité distante n'est pas recon- nue et que la résolution DNS ne peut pas résoudre l'identité. Pour fixer l'identité ISAKMP d'une extrémité, utilisez les commandes suivantes en mo- de de configuration global. Commande But Routeur(config)# crypto isakmp identity {address | hostname} A l'extrémité locale: Spécifie l'identité ISAKMP de l'extrémité avec l'adresse IP ou le nom de host. Routeur(config)# ip host hostname address1 [address2...address8] Aux extrémités distantes: Si l'identité ISAKMP de l'extrémité locale a été spécifiée avec un nom de host , mappez le nom de host avec son adresse IP à toutes les extrémités distantes. (Ceci n'est pas nécessaire si le mapping nom/adresse est fait avec un serveur DNS). ccnp_cch

N'oubliez pas de répéter ces tâches à chaque extrémité qui utilise des clés pré-parta- gées dans une politique IKE. Spécification de toutes les clés publiques RSA des autres extrémités A chacune des extrémités, spécifiez toutes les clés publiques RSA des autres extrémi- tés en utilisant les commandes suivantes et en débutant en mode de configuration global. Commande But Routeur(config)# crypto key pubkey-chain rsa Entre en mode de configuration chaîne clés publiques. Routeur(config-pubkey-c)# named-key key-name [encryption | signature] ou Routeur(config-pubkey-c)# addressed-key key-address [encryption | signature] Indique quelle clé publique RSA de l'extrémité distante vous spécifiez. Entre en mode de con-figuration clé publique. Si l'extrémité distante utilise son nom de host comme identité ISAKMP, utilisez la commande named-key et spécifiez le nom complet de l'extrémité distante ( tel que somerouter.exam- ple.com) comme key-name. Si l'extrémité distante utilise son adresse IP comme identité ISAKMP, utilisez la commande addressed-key et spécifiez l'adresse IP de l'ex-trémité distante comme key-address. Routeur(config-pubkey-k)# address ip-address Si vous utilisez un nom de domaine complet pour nommer l'extrémité distante à la seconde étape, (en utilisant la commande named-key), vous pouvez optionnellement spécifier l'adres-se IP de l'extrémité distante. Routeur(config-pubkey-k)# key-string key-string Spécifie la clé publique de l'extrémité distante. C'est la clé vue par l'administrateur de l'extré-mité distante quand il a généré les clés RSA de son routeur. Routeur(config-pubkey-k)# quit Retour en mode de configuration chaînes de clés publique . Répétez les étapes 2 à 4 pour spécifier les clés publiques RSA de toutes les autres extrémités qui utilisent des nonces RSA cryptées dans une politique IKE. Routeur(config-pubkey-c)# exit Retour en mode de configuration global. N'oubliez pas de répéter ces tâches à chaque extrémité qui utilise des nonces RSA cryptées dans une politique IKE. ccnp_cch

Pour lister les clés publiques RSA pendant ou après la configuration, utilisez la com- mande suivante en mode EXEC privilégié. Commande But Routeur# show crypto key pubkey-chain rsa {name key-name | address key-address} Affiche une liste de toutes les clés publiques RSA stockées sur le routeur ou affiche les détails d'une clé publique RSA particulière stockée sur le routeur. Configuration de clés pré-partagées Pour configurer les clés pré-partagées, exécutez ces tâches à chaque extrémité qui uti- lise des clés pré-partagées dans une politique IKE:  Fixer d'abord l'identité ISAKMP de chaque extrémité. L'identité de chaque extrémité doit être fixée soit avec le nom de host soit avec l'adresse IP. par défaut, l'identité d'une extrémité est fixée avec son adresse IP. Fixer l'identité ISAKMP est décrit dans la section "Fixer l'identité ISAKMP".  Ensuite spécifiez les clés partagées par chaque extrémité. Notez qu'une clé pré-par- tagée donnée est partagée entre deux extrémités. A une extrémité donnée vous pou- vez spécifier la même clé à partager avec plusieurs extrémités distantes; cependant une approche plus sécurisée est de spécifier des clés différentes à partager entre dif- férentes paires d'extrémités. Pour spécifier des clés pré-partagées à une extrémité, utilisez les commandes suivantes en mode de configuration global. Commande But Routeur(config)# crypto isakmp key keystring address peer-address ou Routeur(config)# crypto isakmp key keystring hostname peer-hostname A l'extrémité local: Spécifie la clé partagée de-vant être utilisée avec une extrémité donnée. Si l'extrémité distante a spécifié son identité ISAKMP avec un adresse, utilisez le mot clé address dans cette étape; sinon utilisez le mot clé hostname dans cette étape. A l'extrémité distante: Spécifie la clé partagée utilisée avec l'extrémité locale. C'est la même clé que vous venez de définir pour l'extrémité locale. Si l'extrémité locale a spécifié son identité address dans cette étape; sinon utilisez le mot Répétez les deux étapes précédentes pour cha-que extrémité distante. N'oubliez pas de répéter ces tâches à chaque extrémité qui utilise des clés pré-parta- gées dans une politique IKE. ccnp_cch

ccnp_cch Configuration du mode de configuration IKE "Internet Key Exchange (IKE) Mode Configuration" tel qu'il est défini par l'IETF (Inter- net Engineering Task Force) permet à une passerelle de charger une adresse IP ( et d'autres configuration de niveau réseau) vers le client comme partie de la négociation IKE. En utilisant cet échange, la passerelle donne l'adresse IP au client IKE pour qu'elle soit utilisée comme adresse IP interne encapsulée dans IPsec. Ceci fournit une adresse IP connue au client qui peut être vérifiée avec la politique IPSec (Internet Pro- tocol Security). Pour implémenter les VPNs (Virtual Private Network) IPSec entre des clients d'accès distant avec des adresses dynamiques et une passerelle d'entreprise, vous devez admi- nistrer dynamiquement une politique IPSec évolutive sur la passerelle chaque fois qu'un client est authentifié. Avec la configuration de mode IKE, la passerelle peut met- tre en place une politique évolutive pour un très grand nombre de clients sans tenir compte des adresses IP de ces clients. Il a deux modes de configuration IKE:  Initiation par la passerelle - La passerelle initie le mode de configuration avec le client. Dès que le client répond, IKE modifie l'identité du client, le message est traité et le client reçoit une réponse.  Initiation par le client - Le client initie le mode de configuration avec la passerelle. La passerelle répond avec l'adresse IP qu'elle a alloué au client. Le mode de configuration IKE a les restrictions suivantes:  Les interfaces avec des crypto maps qui sont configurées avec le mode de configura- tion IKE peuvent rencontrer un temps d'établissement de connexion légèrement plus long. Ceci est vrai même pour les extrémités IKE qui refusent d'être configurées ou qui ne répondent pas à la requête du mode de configuration.  Au moment de cette publication, cette fonctionnalité est un "draft" IETF définissant un support limité. Par conséquent cette fonctionnalité n'a pas été conçue pour vali- der par défaut le mode de configuration pour chaque connexion IKE. Configurez cet- te fonctionnalité au niveau de la crypto map globale.  Les items suivants dans le draft IETF ne sont pas supportés: - Attributs de configuration autres que INTERNAL_IP_ADDRESS - Echanges non protégés Il y a deux étapes pour configurer le mode de configuration IKE sur un routeur: 1. Définition du pool d'adresses IP 2. Définissez quelles crypto maps doivent tenter de configurer les clients ccnp_cch

Configuration de Tunnel Endpoint Discovery (TED) Pour configurer le mode de configuration IKE sur votre routeur d'accès Cisco, utilisez les commandes suivantes en mode de configuration global. Commande But routeur(config)# ip local pool pool-name start-addr end-addr Un pool d'adresse local est utilisé pour définir un ensemble d'adresses. Pour définir un pool d'adresses local, utilisez la commande existante ip local pool. Pour plus d'information sur la commande ip local pool, référez-vous à Cisco IOS Dial Services Command Reference. routeur(config)# crypto isakmp client configuration address-pool local pool-name Le pool local référence la configuration IKE. Pour référencer le pool d'adresses local dans la configuration IKE, utilisez la commande crypto isakmp client configuration address-pool local. Pour plus d'information sur la commande crypto isakmp client configuration address-pool local, référez-vous à Cisco IOS Security Command Reference. routeur(config)# crypto map tag client configuration address [initiate | respond] Pour configurer le mode de configuration IKE en en mode de configuration crypto map, utilisez la nouvelle commande cryptomap client configu-ration address. Pour plus d'information sur la commande crypto map client configuration address, référez-vous à Cisco IOS Security Command Reference. Configuration de Tunnel Endpoint Discovery (TED) Tunnel Endpoint Discovery (TED) est une amélioration de la fonctionnalité IPSec. La définition d'une crypto map dynamique vous permet d'avoir la capacité de déterminer dynamiquement les extrémités IPSec; toutefois seul le routeur receveur possède cette capacité. Avec TED, le routeur initiateur peut déterminer dynamiquement une extré- mité IPSec pour des communications IPSec sécurisées. TED aide à la simplification de IPSec sur chacun des routeurs dans un grand réseau. Chaque nœud a une configuration simple qui définit le réseau local à protéger et les paramètres IPSec requis. Pour un grand réseau totalement maillé sans TED, chaque extrémité doit avoir une crypto map statique pour chaque autre extrémité du réseau. Par exemple, s'il y a 100 extrémités dans un grand réseau totalement maillé, chaque routeur doit avoir 99 crypto maps, une pour chacune des autres extrémités. Avec TED, une seule crypto map dynamique avec TED validé est nécessaire car l'extrémité distan- te est découverte dynamiquement. Ainsi les crypto maps statiques n'ont pas besoin d'être configurées pour chaque extrémité. Note: TED aide uniquement à la découverte des extrémités. TED ne fonctionne pas différemment par rapport à IPSec. TED n'améliore pas les performances d'IPSec en termes de nombre d'extrémités ou de tunnels. ccnp_cch

La figure suivante et les étapes correspondantes expliquent un cas de topologie de réseau avec TED. Réseau Host B 2.2.2.5 Host A 1.1.1.1 Routeur1 Routeur2 Etape 1 Le Host A transmet un paquet destiné au Host B. Etape 2 Le Routeur1 intercepte le paquet et le lit. Selon la politique IKE, le Rou- teur1 contient les informations suivantes: le paquet doit être crypté, il n'y a pas de SAs pour le paquet et TED est validé. Le Routeur1 éliminé le paquet et transmet un TED probe dans le réseau. (le TED probe con- tient l'adresse IP du Host A(adresse IP source) et l'adresse IP du Host B (adresse IP destination) dans la charge utile). Etape 3 Le Routeur2 intercepte le TED probe et examine le paquet avec l'ACL qui le protège; après que le paquet soit validé par l'ACL, celui-ci est reconnu comme un TED probe pour le proxy que le routeur protège. Il transmet ensuite un TED reply avec l'adresse IP du Host B (adresse IP source) et l'adresse IP du Host A (adresse IP destination) embarquées dans la charge utile. Etape 4 Le Routeur1 intercepte le TED Reply et vérifie la charge utile pour l'adresse IP et le demi proxy Routeur2. Il combine ensuite le côté de son proxy avec le proxy trouvé dans la seconde charge utile et initie une session IKE avec le Routeuyr2; par la suite le Routeur1 initie une session IPSec avec le Routeur2. Note: IKE ne peut pas être initié tant que l'extrémité n'est pas identifiée. Versions de TED Le tableau suivant liste les versions de TED disponibles: Version Première disponibilité Description TEDv1 12.0(5)T Réalise les fonctionnalités TED de base sur des réseaux non redondants TEDv2 12.1M Amélioré pour fonctionner sur des réseaux redondants avec des chemins au travers de plusieurs passerelles de sécurité entre la source et la destina-tion. Note: TEDv2 est recommandé. ccnp_cch

ccnp_cch Restrictions de TED Tunnel Endpoint Discovery a les restrictions suivantes:  Il est propriétaire Cisco  Il est disponible uniquement avec les crypto maps dynamiques. (Le modèle de cry- pto map dynamique est basé sur la crypto map dynamique réalisant la découverte d'extrémité. Bien qu'il n'y ait pas de restriction de liste d'accès sur le modèle crypto map dynamique, le modèle crypto map dynamique doit couvrir les données issues du trafic protégé et le routeur receveur utilisant le mot clé any. Quand on utilise le mot clé any, il faut inclure des instructions deny explicites pour exclure le trafic du protocole de routage avant d'entrer la commande permit any.)  Il est limité par les performances et l'évolutivité des limitations IPSec de chaque plateforme. Note: Valider TED diminue légèrement l'évolutivité d'IPSec à cause de la surcharge de l'établissement de la découverte d'extrémité qui inclut un échange supplémen- taire de messages IKE (TED probe, TED reply). Bien que assez faible, la ressource mémoire supplémentaire utilisée pour stocker les données pendant la découverte de l'extrémité affecte défavorablement l'évolutivité d'IPSec.  Les adresses IP doivent être routables dans le réseau  La liste d'accès utilisée dans la crypto map pour TED peut uniquement contenir des entrées IP; TCP et UDP ou tout autre protocole ne peut pas être utilisé dans la liste d'accès. Pour créer une entrée de crypto map dynamique avec Tunnel Endpoint Discovery con- figuré, utilisez les commandes suivantes en débutant en mode de configuration crypto map. Commande But Routeur(config)# crypto dynamic-map dynamic-map-name dynamic-map-number Routeur (config-crypto-m)# set transform-set transform-set-name1 [transform-set name2...transform-set-name6] Routeur(config-crypto-m)# match address access-list-id Routeur(config-crypto-m)# set security-association lifetime seconds seconds et/ou Routeur(config-crypto-m)# set security-association lifetime kilobytes kilobytes Routeur(config-crypto-m)# set pfs [group1 | group2] Routeur(config-crypto-m)# exit Configure une crypto map dynamique en utilisant la commande crypto dynamic-map. Note: Vous devez configurer une match address; autrement le comportement est non sécurisé et vous ne pouvez pas valider TED car les paquets sont transmis en clair (non cryptés). ccnp_cch

ccnp_cch Effacer les connexions IKE Commande But Routeur(config)# crypto map map-name map-number ipsec-isakmp dynamic dynamic-map-name [discover] Ajoute une crypto map dynamique à un ensemble crypto map. Entrez le mot clé discover sur la crypto map dynamique pour valider TED. Effacer les connexions IKE Si vous le voulez, vous pouvez effacer les connexions IKE existantes. Pour effacer les connexions IKE existantes, utilisez les commandes suivantes en mode EXEC privilégié. Commande But Routeur# show crypto isakmp sa Affiche les connexions IKE existantes; notez les identifieurs de connexion pour les connexions que vous voulez effacer. Routeur# clear crypto isakmp [connection-id] Efface les connexions IKE. Résolution de problèmes Pour aider à la résolution de problèmes IKE, utilisez les commandes suivantes en mode EXEC privilégié. Commande But Routeur# show crypto isakmp policy Affiche les paramètres pour chaque politique IKE configurée. Routeur# show crypto isakmp sa Affiche toutes les associations de sécurité IKE courantes. Routeur# show running-config Vérifie la configuration IKE. Routeur# debug crypto isakmp Affiche les messages debug concernant les évènements IKE. ccnp_cch

Exemples de configuration IKE Cet exemple crée deux politiques IKE, avec la politique 15 comme politique de priorité la plus élevée suivie de la politique 20 et la politique par défaut existante avec la prio- rité la plus basse. Il crée également une clé pré-partagée devant être utilisée avec la po- litique 20 et avec l'extrémité distante dont l'adresse IP est 192.168.224.33. crypto isakmp policy 15 encryption 3des hash md5 authentication rsa-sig group 2 lifetime 5000 crypto isakmp policy 20 authentication pre-share lifetime 10000 crypto isakmp key 1234567890 address 192.168.224.33 Dans l'exemple précédent, encryption des de la politique 15 n'apparaît pas dans la configuration écrite car c'est la valeur par défaut pour le paramètre algorithme de cryptage. Si la commande show crypto isakmp policy est entrée avec cette configuration, la sortie serait celle-ci: Protection suite priority 15 encryption algorithm:3DES - Triple Data Encryption Standard (168 bit keys) hash algorithm:Message Digest 5 authentication method:Rivest-Shamir-Adleman Signature Diffie-Hellman group:#2 (1024 bit) lifetime:5000 seconds, no volume limit Protection suite priority 20 encryption algorithm:DES - Data Encryption Standard (56 bit keys) hash algorithm:Secure Hash Standard authentication method:Pre-Shared Key Diffie-Hellman group:#1 (768 bit) lifetime:10000 seconds, no volume limit Default protection suite lifetime:86400 seconds, no volume limit Notez que bien que cette sortie montre "no volume limit" pour les durées de vie, vous pouvez configurer une durée de vie uniquement en temps (comme 86400 secondes); les durées de vie limitées en volume ne sont pas configurables. ccnp_cch