Latest revision as of 10:17, 14 February 2006

IKE Version 2

Table des matières

Architectures classiques de mise en oeuvre des IPsec

L'utilisation de la cryptographie à clé publique à grande échelle nécessite de pouvoir gérer des listes importantes de clés publiques, pour des entités souvent réparties dans un réseau. Pour cela, on a recours à des infrastructures à clés publiques (PKI : Public Key Infrastructures) qui sont des systèmes de gestion de clés publiques.

Ces PKI gèrent bien souvent les clés publiques sous forme de certificats, mais il est tout à fait possible de se passer des certificats pour assurer la gestion des clés publiques. Après une présentation des certificats et des listes de certificats révoqués (CRL : Certificate Revocation List), l'organisation et le fonctionnement général des PKIs sont décrits.

Certificats X.509 et CRL

Un certificat de clé publique permet d'associer une clé publique à une entité (serveur, PC, individu...) de façon sûre, c'est-à-dire certifiée par une autorité de certification (AC : Autorité de Certification) habilitée qui signe chacun des certificats qu'elle a émis. La grande majorité des certificats aujourd'hui utilisés se base sur la norme X.509V3 qui définit plusieurs champs incluant :

• Version : le numéro de version de la norme X.509 à laquelle se rapporte le certificat ;
• Numéro de série : le numéro unique correspondant à un certificat généré par une autorité de certification ;
• Emetteur : l'identifiant de l'autorité de certification émettrice du certificat ;
• Période de validité : les dates de début et de fin de validité du certificat ;
• Sujet : l'identifiant du propriétaire du certificat ;
• Clé publique : la clé publique associée au propriétaire du certificat ;
• Signature : la signature électronique de l'autorité de certification portant sur tout le contenu du certificat pour en assurer l'authenticité ;
• Extensions : de nombreuses extensions peuvent être ajoutées au certificat par l'autorité de certification comme l'usage qui doit être fait de la clé publique.

Avant même que le certificat n'arrive à expiration, de nombreuses raisons comme la compromission de la clé privée associée au certificat, l'impossibilité pour l'autorité de certification de continuer à enregistrer le certificat, peuvent amener le certificat à être révoqué. La technique la plus répandue aujourd'hui consiste pour l'autorité de certification à générer périodiquement une liste CRL contenant les numéros de série des certificats révoqués, ainsi que la date de génération de la CRL et la date attendue pour la prochaine mise à jour de la CRL. L'authenticité de cette liste est assurée par l'AC par le biais de sa signature.

PKI : principe et lacunes actuelles

Une PKI (Public Key Infrastructure) ou IGC (Infrastructure de Gestion de Clés) permet de définir des entités fonctionnelles, chacune avec un rôle bien précis, le but étant d'offrir un environnement de confiance ainsi que des garanties quant à l'authenticité des certificats de clés publiques. La gestion des certificats est opérée au sein de la PKI par trois entités :

• Autorité de certification (AC) : l'organisme qui émet des certificats électroniques (par exemple CertPlus, Certinomis, Verisign) ;
• Autorité d'enregistrement : l'entité réalisant l'interface entre les entités demandeuses de certificats et l'autorité de certification chargée de vérifier l'identité du demandeur de façon plus ou moins forte (par exemple présentation d'une carte d'identité) ;
• Système de publication et de distribution de certificats et CRL : l'entité chargée par l'autorité de certification de publier et distribuer des certificats électroniques et des CRL, ce qui peut être réalisé classiquement par le biais d'un annuaire LDAP (Lightweight Directory Access Protocol) ou d'un serveur Web.

Une PKI est généralement organisée en une hiérarchie d'autorité de certifications, chacune de ces autorité étant responsable de la gestion d'un sous-ensemble de certificats et de CRL. Dans cette hiérarchie, une autorité de certification habilite une autorité de niveau inférieur à gérer les certificats de la PKI en lui générant un certificat pour sa propre clé publique ; elle lui prouve ainsi sa confiance. L'AC racine n'ayant aucune AC au dessus certifie elle-même sa propre clé publique ; le certificat de l'AC racine est appelé certificat auto-signé.

En fait, une PKI doit être capable de rendre les quatre fonctions suivantes :

• L'enrôlement qui consiste optionnellement à générer une clé publique/privée, à vérifier l'identité de l'entité demandeuse, et de façon obligatoire à distribuer des clés privées et certificat ;
• La publication de certificats de clé publique, c'est-à-dire à maintenir disponible les certificats pour des entités tiers demandeuses ;
• La validation de certificats qui doit permettre de renseigner n'importe quelle entité sur l'état de validité d'un certificat, et ce à tout moment ;
• La révocation de certificats qui consiste généralement à publier une CRL.

Si aujourd'hui la distribution et la publication de clés sont aisément résolues avec la distribution et la publication de clés/certificats par le biais d'un support comme une clé USB, ou une carte à puce, voire la publication de certificats via un annuaire LDAP par exemple, en revanche la révocation et la vérification de clés ne le sont pas ou imposent certaines limitations d'usage. En effet, de nombreuses PKIs existent actuellement et s'ignorent de sorte que pour vérifier la validité d'un certificat, il est nécessaire de connaître et d'avoir confiance dans l'AC émettrice. Pour la plupart des équipements IPsec, un certificat est considéré valide uniquement s'il est émis par la même autorité de certification dont il dépend ; au mieux, il est possible d'étendre cette validité à des certificats émis par une autre autorité de certification à la condition de précharger le certificat dans l'équipement. Noter que pour toutes ces raisons, l'établissement d'un VPN (Virtual Private Network) sécurisé ne peut pas s'improviser. Certaines solutions tentant de rendre les VPNs dynamiques et appelées « chiffrement opportuniste » voient cependant le jour à l'IETF.

Outils et protocoles de mise en oeuvre des PKIs

Plusieurs outils logiciels opensource permettent de gérer des certificats de clé publique :

• L'enrôlement et la révocation de certificats sont assurés par le logiciel OpenCA développé par The OpenCA Labs. OpenCA se base sur Apache et permet donc aux administrateurs/utilisateurs de réaliser toute la gestion des certificats au travers d'un navigateur classique. Suivant le répertoire auquel on accède sur le serveur OpenCA, un utilisateur jouera le rôle de l'autorité de certification ou de l'autorité d'enregistrement.

OpenCA bénéficie de plusieurs avantages vis-à-vis d'autres logiciels de gestion de certificats comme IDEALX. En effet, il est relativement simple d'installation et de plus il s'interface avec OpenLDAP ce qui permet, une fois les certificats générés, de les publier de façon automatique dans la base LDAP.

• La publication des certificats et CRL est réalisée par openLDAP développé par The OpenLDAP Project. Depuis 1999, avec les nouveaux attributs de LDAP définis dans le RFC 2587, il est possible de publier un certificat mais aussi une CRL dans une entrée de LDAP.

Quant à l'aspect validation, toute la difficulté est d'obliger les applications utilisatrices de certificats de vérifier la validité d'un certificat avant usage. Aujourd'hui, certaines applications comme Netscape 7 implémentent le protocole OCSP (Online Certificate Status Protocol) [RFC 2560] qui permet à une application d'interroger un serveur OCSP en ligne pour connaître la validité d'un certificat. Le serveur OCSP attaché à une autorité de certification se contente en fait de vérifier le statut d'un certificat stocké en local dans un de ces répertoires ; le certificat précise dans un champ l'adresse du serveur OCSP à contacter. Un autre protocole SCVP (Simple Certificate Validation Protocol) [MHF-id] est en cours de définition à l'IETF. Le serveur SCVP qui est local à l'application demandeuse est capable de vérifier la validité de n'importe quel certificat pour peu qu'il ait confiance dans la PKI concernée.

DNSSEC (Domain Name System Security)

DNSSEC [RFC 2535] est un standard définissant des extensions de sécurité pour le DNS. Il vise à assurer l'intégrité et l'authenticité des enregistrements DNS (RR : Registration Record) en introduisant des signatures électroniques (RRSIG RR) calculées par la zone sécurisée DNSSEC sur des enregistrements DNS. Plus exactement, chaque zone dispose de deux paires de clés publiques/privées appelées Key Signing Key (KSK) et Zone Signing Key (ZSK). La clé publique de KSK est connue de la zone parent et lui permet donc d'authentifier sa zone fille, tandis que les clés ZSK permettent de signer les enregistrements gérés par la zone elle-même.

Il est tout à fait possible de superposer une PKI sur la hiérarchie DNS. En effet, chaque zone DNSSEC peut jouer le rôle d'une autorité de certification. Il lui suffit de certifier la clé publique de sa zone fille en signant le condensat de cette clé et en publiant ce condensat dans l'enregistrement DS RR (Delegation Signer) [RFC 3658]. La zone fille publie sa clé publique KSK dans l'enregistrement DNSKEY RR prévu à cet effet et signe cet enregistrement avec sa clé privée KSK. Ainsi, il suffit donc d'avoir confiance dans la zone parent pour récupérer en toute confiance la clé publique KSK de la zone fille. Il est alors possible d'avoir confiance dans la clé ZSK publiée dans un DNSSKEY RR et signée par la zone fille avec sa clé privée KSK (RRSIG RR). De proche en proche, on peut mettre en place une PKI, avec chaque zone définissant une autorité de certification intermédiaire et une autorité de certification racine correspondant à la zone DNSSEC de plus haut niveau dans la hiérarchie.

Pour publier des clés publiques associées à des noms DNS ou des adresses IP, DNSSEC prévoit l'usage de l'enregistrement DNSKEY RR protégé par les enregistrements RRSIG RR, ainsi que l'usage de l'enregistrement CERT RR, lui aussi protégé par RRSIG RR et qui peut inclure un certificat ou une CRL. La confiance dans la clé publique est à chaque fois garantie par la PKI DNS, mais dans le cas du CERT RR, la clé publique publiée est en plus gérée par une autorité de certification extérieure au DNS.

Il serait techniquement possible de gérer des CRLs et des clés publiques d'équipements IPsec par le biais de DNSSEC, mais cette utilisation de DNSSEC n'est pas recommandée car ces informations ont une durée de vie relativement courte (déplacement d'équipements, renouvellement fréquent des CRLs) et DNSSEC ne permet pas leur prise en compte immédiate du fait de la gestion des caches DNS.

Host Identity Protocol (HIP)

HIP [Mos-id] est une solution qui peut servir en remplacement des PKIs en prenant une clé publique comme identifiant d'un équipement IPsec. Plus généralement, HIP repose sur le principe de distinguer l'identité d'une machine (son identifiant) et le moyen de l'atteindre (son localisateur). Aujourd'hui, l'identifiant et le localisateur sont confondus dans l'adresse IP, mais HIP suggère de garder pour localisateur l'adresse IP et de considérer un nouvel identifiant HI (Host Identifier).

Il est recommandé de prendre pour HI d'un équipement IPsec la ou l'une des clés publiques associées à l'équipement. Ainsi, son exploitation sera immédiate lors de la phase d'authentification lors des échanges IKE. Bien entendu, il est nécessaire de publier le lien entre le localisateur et l'identifiant HI, en particulier, pour gérer la mobilité des équipements IPsec. Une solution consiste à associer au nom canonique d'un équipement son adresse IP ainsi que son HI. Noter que le HI étant de longueur trop importante, les équipements IPsec vont s'échanger leurs identifiants sous la forme du condensat du HI ; ce condensat qui fournit une valeur hachée sur 128 bits est appelé Host Identity Tag (HIT).

IKE Version 2

Table des matières

Architectures classiques de mise en oeuvre des IPsec