Le protocole IMEP : une architecture d'authentification MANET
Résumé
L' "Internet MANET Encapsulation Protocol" (IMEP) a été élaboré pour supporter les opérations de nombreux algorithmes de routage ou d'autres protocoles de couches supérieures dans les réseaux mobiles ad hoc. L'environnement MANET est très différent des autres environnements informatiquesde par le fait que ces ordinateurs mobiles seront connectés aux réseaux via des liens mobiles. De tels liens sont particulièrement vulnérables aux écoutes passives, aux séquences rejouées, aux techniques de spoofing et autres attaques. L'utilisation d'IMEP est le résultat de la dépendance des noeuds mobiles sur les autres noeuds MANET pour réaliser les opérations de routage. Cette fonction de routage constitue une vulnérabilité importante si la gestion des messages IMEP n'est pas authentifiée. Les risques d'attaques sur les messages de contrôle de routage MANET nécessitent une architecture d'authentification afin de protéger ces messages dans certains contextes. Ainsi, tous les noeuds du réseau doivent être capables d'utiliser des procédures d'authentification. Cette architecture d'authentification MANET fournit aux routeurs le choix entre plusieurs options, simples ou complexes en passant par aucune authentification dans certains cas.
Ce document décrit la manière dont les noeuds MANET utilisant IMEP et désirant passer par des méthodes d'authentification doivent eux-même authentifier les messages IMEP. Les mécanismes décrits ici vont permettre aux noeuds d'utiliser soit des techniques de codage de type clé secrète soit des techniques de codage de type clé publique (avec certifications et signatures digitales) pour la gestion des messages d'authentification IMEP. L'utilisation de mécanismes de clés secrètes favorise la recherche et l'expérimentation des réseaux MANET alors que l'utilisation de clés publiques permet à MANET de gérer des milliers de noeuds mobiles.
1. Introduction
Lorsque l'on examine les différents types d'implémentation MANET, on peut constater qu'ils utilisent des environnements très différents. Les bancs de test de recherche tournent sur des environnements relativement pauvres, ils fournissent au réseau des bandes-passantes de quelques Kbps à quelques Mbps. Les plus grandes craintes ainsi que les principaux axes de recherches sont focalisés aujourd'hui sur l'augmentation de cette bande-passante. Les déploiements militaires doivent faire face à des environnements très hostiles en matière de sécurité, avec des bandes-passantes allant de 4.8kbps à quelques Mbps.
Le nombre et la fréquence des messages de contrôle ("protocol control messages") a un impact direct sur un protocol comme MANET. Cette impact est principalement visible sur la bande-passante des réseaux. Comme cette bande-passant diminue, la longueur des en-têtes des messages doit donc être minimisée. Les environnements MANET sont confrontés à des craintes et aux niveaux de risque qui leur est associé. Il va donc falloir prendre en compte le degré de risque acceptable et le coût des en-têtes nécessaire à une sécurité optimale.
Il existe un certain nombre de methodes concernant les messages d'authentification comme les clés secrètes, les certificats publics et auto-signés, ... Pour chaque méthode d'authentification, il existe à la fois des approches de distribution de clés manuelles et des approches de distribution de clés dynamiques comme le protocole d'échange de clés sur Internet ("Internet Key Exchange protocol (IKE)") ou bien LDAP ou encore DNS. Les certificats contenant des clés publiques peuvent également être distribués de deux manières : manuelle ou dynamique. Alors que la distribution manuelle de clé nécessite uniquement des informations présentes sur chaque noeud du réseau, la distribution dynamique en revanche a un impact direct sur la taille de l'en-tête des messages de contrôle et influe donc sur la bande-passante de ces réseaux. Lorsque le nombre de noeuds augmente, le nombre de clés publiques augmente plus rapidement en : (noeuds x (noeuds-1))(noeuds x (noeuds-1))/2 ce qui devient inacceptable très rapidement.
Seront traités dans ce document :
* l'utilisation des certificats digitaux X.509
* les certificats digitaux issus des "Certificate Authorities (CAs)"
* les certificats de type PGP
* l'utilisation soit des adresses IP soit des noms d'hôte pour identifier les noeuds MANET
* la révocation et la vérification des certificats digitaux.
1.1. Terminologie
Cette section fournit des définitions concernant les termes employés dans ce document.
Certification Authority (CA) : il s'agit d'un tiers de confiance entre un ou plusieurs utilisateurs ayant pour objectif la création et l'assignation des "certificats digitaux". Tous les CAs nécessitent non seulement de maintenir une base de données de noms distincts ("Distinguished Names" (DNs)) qu'ils certifient mais aussi de s'assurer qu'ils ne certifient pas des duplications de DNs.
Certificate-Revocation List (CRL) : structure de données contenant des informations sur les certificats dont la validité a été prématurément révoquée par l'émetteur. L'information correspond au nom de cet émetteur, la date de l'émission, l'heure planifiée de la prochaine émission et une liste de numéros de série de certificats et l'heure de révocation associée. La CRL est signée par l'émetteur. Cette structure de la donnée est spécifiée dans la RFC1422.
Certificate Subject : un "Certificate Subject" ou "Subject" est l'entité référencée comme nom distinct et contenue à l'intérieur du certificat.
Digital Certificate : ou "Certificate" est une structure de données qui relie un nom distinct à une clé publique avec une signature digitale. Cette structure de données est définie dans X.509 et contient certaines informations comme l'identifiant et la clé publique d'une entité où une autorité appelée "Certification Authority" (CA) a relié de manière codée les informations entre elles en utilisant une signature digitale.
Digital Certification : c'est un mécanisme dans lequel une autorité de certification (CA) signe une structure de données spéciale contenant le nom de certaines entités et leur clé publique de telle sorte que n'importe qui puisse vérifier que le message a été signé par personne excepté l'autorité de certification (CA) et fournit ainsi une confiance dans la clé publique de l'entité.
Digital Signature : le contenu qui doit être signé est d'abord réduit en un message sommaire avec un algorithme comme MD5 et ensuite, il est codé avec la clé privée RSA du signataire du contenu.
Distinguished Name (DN) : permet de définir un chemin à travers un répertoire X.500 à partir de la racine jusqu'à l'objet désiré.
MANET router : dispositif, distingué par un identifiant unique de routeur (RID) qui exécute un protocole de routage MANET et, sous la direction duquel il fait suivre les paquets IP. Il peut avoir différentes interfaces, chacune d'elle identifiée par une adresse IP. Un dipositif de gestion de la couche physique est associé à chaque interface, filaire ou sans fil. Les routeurs peuvent utiliser ces différentes technologies. Par exemple, un routeur MANET peut connecter 4 interfaces possédant des technologies de communication différentes comme FFDI, Ethernet, Spread Spectrum et les impulsions radio.
MANET Security Association (MSA) : il s'agit d'une suite de contextes de sécurité entre une paire de noeuds qui peut être appliquée au protocole IMEP. Chaque contexte indique un algorithme et un mode d'authentification.
Message-Digest Algorithm : c'est une méthode de réduction des messages de n'importe quelle longueur en des messages de longueur fixe, appelés "message-disgest". Les algorithmes permettant celà sont décrits dans les RFC1319 et RFC1321. Chacun d'eux fournit un message de sortie de 128 bits.
Public-key algorithm : il s'agit d'un algorithme de chiffrement et de déchiffrage des données avec clés publique/privée.
Public-key cryptography
RSA
Security Context
Security Parameter Index (SPI)
Self-Signed Digital Certificate
X.509 Digital Certificate
X.509 Digital Certification
1.2. Spécification du langage
Ce document utilise les termes "MUST", "SHOULD", "MAY" comme définis dans la RFC2119.
1.3. Augmentation de la sécurité
Le but de l'architecture d'authentification MANET (MAA) est de fournir un mécanisme extensible capable de supporter des techniques dites lourdes (hautement sécurisées).
2. Vue d'ensembe de l'architecture
Les options d'authenfication peuvent être de simples à complexes en permettant même la possibilité de refuser tout système de sécurité (mode par défaut). Les messages IMEP circulant entre les routeurs MANET sont identifiés avec ce qui est appelé "the IMEP authentification objects". Cette notion (vue en section 3.2) identifie un contexte de sécurité entre une paire de noeuds et est fondamentale dans la définition d'une MSA entre ces noeuds. Elle suit des objets non authentifiés et peut éventuellement être suivit d'objets appelés "Certificate Object" (vus en section 3.3) si la MSA entre ces noeuds le nécessite.
L'architecture MAA oblige l'utilisation d'un objet d'authentification dans TOUS les messages IMEP. En revanche, l'utilisation de certificats est optionnelle, cela dépend du contexte de sécurité en accord entre les noeuds.
2.1. Fonctionnement des objets d'authentification
MAA nécessite que les messages IMEP incluent un objet <AUTH> qui utilise une signature digitale pour authentifier le contenu du message et parfois un objet <CERT> de telle sorte que les noeuds qui reçoivent peuvent obtenir rapidement une copie authentique de la clé publique de l'émetteur.
Les étapes suivies lorsqu'un noeud reçoit un message IMEP sont les suivantes :
1. Le noeud localise l'objet <AUTH> et si aucun n'est trouvé, le récepteur cesse tout processus d'authentification et considère le message comme non authentique. L'émetteur n'est pas autorisé à utiliser le réseau MANET, le récepteur note l'échec d'authentification et ignore le message reçu.
2. Si le noeud trouve différents objets <AUTH>, le récepteur adopte exactement la même procédure qu'en 1.
3. Dans le dernier cas (un et un seul objet <AUTH>), le récepteur extrait la valeur de l'objet <AUTH> (champ <AUTH_TYPE>), qui identifie le MSA ainsi que la valeur du champ <AUTHENTICATOR> qui détermine l'algorithme et le type de codage qui va être utilisé. Si la valeur du champ <AUTH_TYPE> est positionnée à 001, l'authentification est de type clé secrète et il faut alors suivre la procédure 4b. Lorsque <AUTH_TYPE> a une valeur supérieure à 009, l'authentification est de type clé publique et il faut alors suivre la procédure 4a. Dans les autres cas (001< <AUTH_TYPE> <009), il s'agit d'un utilisateur unique et le fonctionnement dépasse le cadre de ce document. Toutes les valeurs du champ <AUTH_TYPE> sont répertoriées dans le tableau ci-dessous :
Types valides d'authentification
Valeur du champ <AUCH_TYPE>
Algorithme d'authentification
Longueur de la clé en bits
Longueur de la signature digitale en octets
001
Clé secrète et MD5
128
16
002 à 009
Défini par l'utilisateur
Défini par l'utilisateur
Défini par l'utilisateur
011
RSA
512
64
012
RSA
768
97
013
RSA
1024
128
014
RSA
2048
256
021
Elliptic Curve
80
10
022
Elliptic Curve
120
15
023
Elliptic Curve
160
20
030
DSA
512
64
Objets <AUTH> de type clé publique
Procédure suivie lorque le noeud reçoit un message IMEP d'authentification utilisant un mécanisme de clé publique :
4a. Le noeud MANET récepteur localise l'objet <CERT> et si aucun n'est trouvé, le récepteur cesse tout processus d'authentification et considère le message comme non authentique. Le récepteur note l'échec d'authentification et ignore le message reçu.
5a. Le noeud extrait les certificats à partir de l'objet <CERT> et dans le cas où les noeuds émetteur et récepteur partagent la même CA ou des certificats auto-signés, le récepteur utilise la CA.
6a. Dans le cas où les noeuds émetteur et récepteur ne partagent pas la même CA alors, le récepteur utilise n'importe quel autre certificat contenu dans l'objet <CERT> pour établir un chemin de confiance entre la CA du récepteur et celle de l'émetteur.
7a. Lorsque le récepteur est incapable d'établir un chemin de confiance entre les CA, il cesse tout processus d'authentification, considère le message comme non authentique tout en notant l'échec d'authentification et ignore celui-ci.
8a. Supposons que le récepteur ait réussi à établir un chemin de confiance entre les CA. Le récepteur procède alors à la vérification des certificats du CA, s'arrêtant quand le certificat de l'expéditeur a été vérifié.
9a. Le récepteur utilise la clé publique de l'émetteur à partir de son certificat afin de vérifier le champ <AUTHENTICATOR> de l'objet <AUTH> créé grâce à la clé privée de l'émetteur.
10a. Après la réussite de la vérification du champ <AUTHENTICATOR> de l'objet <AUTH>, le récepteur continue le traitement normal du message IMEP comme indiqué dans le protocole de base. Dans le cas où la vérification précédente aboutit à un échec, le récepteur cesse tout processus d'authentification et considère le message comme non authentique. Le récepteur note l'échec d'authentification et ignore le message reçu.
L'objet d'authentification est utilisé pour authentifier tous les messages IMEP. Cette tâche est accomplie en calculant un identifiant (une signature digitale) à partir des champs du message IMEP authentifié. Le champ <AUTH_TYPE> de l'objet <AUTH> défini le contexte de sécurité utilisé pour calculer la valeur de <AUTHENTICATOR> (l'identifiant) qui DOIT être employé par le récepteur. Composition de l'objet <AUTH> :
<AUTH_TYPE> (Type d'authentification) (1 octet) : Objet identifiant le contexte de sécurité et le type d'association de sécurité MANET utilisé entre les algorithmes de signature de deux noeuds. Les valeurs valides utilisées pour la zone < AUTH_TYPE > sont exposées dans le tableau ci-dessous.
<SPI> (1 octet) : L'index de type paramètre de sécurité ("Security Parameter Index (SPI)"), lorsqu'il n'est pas nul, défini le MSA utilisé pour calculer la valeur de l'authentifiant et est également utilisé par le recepteur pour vérifier celui-ci. En particulier, le SPI sélectionne un algorithme, un mode et une clé secrète d'authentification (Section 5.1). Quand le champ <AUTH_TYPE> contient une valeur supérieure à 001, le SPI doit être fixé 0.
<AUTH_LENGTH> (1 octet) : Longueur en octets du champ <AUTHENTICATOR>.
<AUTHENTICATOR> : Valeur calculée.
Un et un seul objet <AUTH> doit être présent dans chaque message IMEP. La table précédente référence les relations entre les tailles des champs <AUTH_TYPE> et <AUTHENTICATOR>. D'autres valeurs du champ <AUTH_TYPE> pourront être définies plus tard.
3.3 <CERT>, l'objet de certification IMEP
L'objet de certification <CERT> est utilisé pour transférer les informations d'authentification (certificats) entre les noeuds MANET comuniquant lorsque la valeur du champ <AUTH_TYPE> de l'objet <AUTH> est supérieure à 001. Les champs de l'objet <CERT> sont les suivants :
<CERT_OBJECT_LENGTH> (2 octets) : La taille de l'objet <CERT> en octets.
<CERT_CNT> (2 octets) : Le nombre de certificats contenus dans l'objet <CERT>.
<SENDER_CERT_LENGTH> (2 octets) : Longueur en octets du certificat X.509 de type 3 du message émis.
<SENDER_CERT> : Certificat X.509 de type 3 du message provenant de l'émetteur et qui contient la clé publique de l'émetteur.
<CA_CERT_LENGTH> (2 octets)
<CA_CERT> (taille variable)
3.4. L'authentification IMEP
3.4.1. Authentification avec <AUTH_TYPE> = 001
Lorsque <AUCH_TYPE> vaut 001, l'authentifiant est calculé en utilisant un chiffrement de type MD5 (RFC1321) afin de calculer une signature digitale sur 128 bits. On trouve dans cet identifiant :
- la clé secrète partagée, définie par la "MANET Security Association" entre les noeuds et la valeur du <SPI> spécifiée dans l'objet <AUTH>
- les champs protégés du message IMEP
- une nouvelle fois la clé secrète partagée.
On peut noter que le champ <AUTHENTICATOR> lui-même n'est pas inclus dans le calcul de la valeur de l'identifiant. Le SPI (paramètre index de sécurité) défini le contexte de sécurité qui est utilisé pour calculer l'authentifiant. Le recepteur est OBLIGE de l'utiliser pour vérifier cette valeur. En particulier, le SPI sélectionne l'algorithme d'authentification et la clé secrète partagée utilisés pour le calcul. Pour que l'authentification de type MD5 soit utile, la clé doit être à la fois secrète et pseudo-aléatoire. Il est de la responsabilité de celui qui impléménte l'algorithme de précharger les clés secrètes et les valeurs de SPI associées à l'intérieur des noeuds MANET qui l'utilisent.
3.4.2. Authentification avec <AUTH_TYPE> > 009
Le programme dit de "hachage MD5" est utilisé dans le but de fournir des "message digest" de 128 bits mentionnés plus haut à partir des messages IMEP. Ceux-ci sont ensuite encodés en utilisant l'algorithme d'authentification à base de clé publique en complément d'une clé privée de longueur spécifique resultant d'un calcul basé sur les champs d'un message IMEP.
3.5. Configuration et enregistrement des tables
Les noeuds utilisant <AUTH_TYPE>=001 DOIVENT être configurés avec les MSAs (contextes de sécurité) de chaque noeud avec lesquels ils interagissent.
Les noeuds utilisant des champs <AUTH_TYPE> dont la valeur est supérieure à 009 doivent être configurés avec un certificat X.509, soit auto-signé soit issu d'un CA et d'une copie de celui-ci.
D'autres éléments présents dans le document original n'ont pas été traduits :
