:: News .:. Documents .:. Forum .:. Downloads .:. Bibliographie .:. Liens .:. Contact  :: 


Home
  :. News
  .: Documents
    .: Notions
    .: Protocoles
    .: Sécurité
    .: Architecture
    .: Prog
    .: Systèmes
  :. Forum
  .: Downloads
  :. Bibliographie
  .: Liens
  :. Contact

Chat

  Nickname:


irc: #guill.net

Forum



 
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'authentificationLongueur de la clé en bitsLongueur de la signature digitale en octets
001Clé secrète et MD512816
002 à 009Défini par l'utilisateurDéfini par l'utilisateurDéfini par l'utilisateur
011RSA51264
012RSA76897
013RSA1024128
014RSA2048256
021Elliptic Curve8010
022Elliptic Curve12015
023Elliptic Curve16020
030DSA51264

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.

3 Messages IMEP et format des objets

3.1 format des messages IMEP

Composition des différents champs :

   <IMEP message>
   <IMEP_MSGHDR>
   <IMEP_OBJECTLIST>
   <IMEP_OBJECT>
   <OBJECT_HDR>
   <RELIABLE_OBJECT>
   <UNRELIABLE_OBJECT>
   <DATA>             :  <ECHO>
                              |  <BCAST>
                              |  <MCAST> <DELIVERY_LIST>
                              |  <MR>
                              |  <ACK>
                              |  <NEWCOLOR>
                              |  <MRA>
                              |  <AUTH>
                              |  <CERT>
   <BCAST>
  <MCAST>
   <MR>

3.2 <AUTH>, l'objet d'identification IMEP

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> :

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                               |  <AUTH_TYPE>  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    <SPI>      | <AUTH_LENGTH> |       <AUTHENTICATOR> ...     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             <AUTHENTICATOR>, continued ...                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   <AUTHENTICATOR>, continued                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<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.

       ----------------------------------------------------------------
       | AUTH_TYPE | Authentication |  Key Length  | Digital Signature|
       |  Value    |   Algorithm    |  in bits     | Length in bytes  |
       |-----------|----------------|--------------|------------------|
       |   001     |Secret Key & MD5|     128      |        16        |
       |002 to 009 |  User Defined  | User Defined |     User Defined |
       |   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        |
       ----------------------------------------------------------------

<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 :

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     <CERT_OBJECT_LENGTH>      |          <CERT_CNT>           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      <SENDER_CERT_LENGTH>     |         <SENDER_CERT>  ...    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               <SENDER_CERT>, continued ...                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        <CA_CERT_LENGTH>       |        <CA_CERT>  ...         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   <CA_CERT>, continued  ...                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   additional <CA_CERT>s as necessary          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<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 :

4. Certificats

5. Confiance

6. Liste de révocation des certificats

 




Sondage

Quel est votre connexion à Internet aujourd'hui ?
 
RTC 56Kbps
ADSL simple de 128 à 2048 Kbps
ADSL + Téléphonie (+TV) de 128 à 2048 Kbps
ADSL simple jusqu'à 20Mbps
ADSL + Téléphonie (+TV) jusqu'à 20Mbps
Autres (RNIS, Satellites bi-directionnel...)
Total :
2884

Recherche


Docs
   Pflogsumm (Analyseur de log mail pour Postfix)
   Proftpd (Mise en service d'un serveur FTP avec proftpd sous Linux)
   Openldap (Mise en service d'un serveur LDAP sous Linux)
   Gestion des périphériques en c++ builder (Communication RS232 en C++ Builder)
   Les sockets windows (Windows Sockets : un cours accéléré)

guill.net©1999-2018