forme de fichiers de journalisation, créés par le MAS et reçues par chaque SAS après son élection. Elles portent sur les durées de connexions des nœuds calculées entre les moments de leur authentification et les dates de leur départ.
Chaque nœud ad hoc dans le système SESSI [65] possède un dépôt sous forme d’une base de données SQL (Structured Query Language) contenant les éléments d’accréditation des clients, à savoir leurs clés publiques certifiées par une autorité tierce ou par le nœud lui même. Ce dépôt contient aussi les différentes clés que le client a pu négocier ou dériver après son authentification auprès des services auxquels il a accédé. Il comprend, d’autre part, une liste de contrôle d’accès dans laquelle le nœud définit l’ensemble des nœuds ad hoc ayant le droit d’accéder aux services qu’il propose et leur niveau d’accès. Il contient, d’un autre côté, l’ensemble des services auxquels le nœud a droit.
Dans les modèles de Lamsal [68], pour chaque nœud du réseau, un nœud enregistre dans son cache un triplet portant sur les ressources auxquelles il a droit d’accéder, le type de droit (par exemple lecture ou écriture) et la valeur de la confiance qu’il a en lui. Une valeur entre 0 et 5 signifie une absence de confiance quand elle vaut 0 et une confiance totale quand elle vaut 5. Une politique d’acceptation d’un nœud arrivant peut être fixée. Par exemple, selon le modèle d’architecture AAA, les serveurs et/ou les nœuds collaborant évaluent la demande de ce nœud et la confronte aux triplets le concernant se trouvant dans leurs caches. Ils prennent en compte aussi leurs capacités à prendre en charge le nœud arrivant car ils peuvent décider de préserver leur énergie pour des situation de nécessité.
La solution de Moustafa et al. [64] utilise la table de routage de chaque nœud pour noter les nœuds voisins qui sont authentifiés et ceux qui ne le sont pas. Ainsi avant de faire acheminer son trafic par un voisin, il consulte sa table et ne s’adresse qu’à un voisin authentifié. La solution DoCoMo [63] préconise que l’opérateur d’un nœud distributeur envoie des données contenant son propre certificat et le certificat de chacun des opérateurs avec qui il a conclu un accord. De cette façon, le nœud distributeur peut reconnaître les utilisateurs enregistrés avec ces opérateurs.
3.4.2
Architecture matérielle et logicielle
SAACCESS propose une architecture matérielle et logicielle des nœuds ad hoc qui sépare ce qui relève de certains des services AAA et qui doit être contrôlé par l’opérateur, de ce qui relève de services de contenus qui doit être contrôlé par le fournisseur de contenus et, enfin, de ce qui relève de l’utilisation quotidienne du terminal par son propriétaire.
3.5 Discussion
L’étude que nous avons menée à la section précédente a permis de mettre en lumière les avancées qui ont été réalisées à ce jour dans la conception de services AAA pour les utilisateurs de MANETs. Elle a montré que les efforts de recherche ont été surtout concentrés sur les MANETs vus comme une extension d’un réseau à infrastructure. En effet, la présence d’un ou plusieurs opérateurs,
parfois désignés simplement par autorité/tiers de confiance ou schématisés par un simple serveur, a été jugée nécessaire pour permettre de créer une relation de confiance entre les nœuds ad hoc et/ou pour collecter les informations pour les besoins de la comptabilité.
Les solutions que nous avons classées dans la catégorie de MANETs totale- ment tributaires décrivent des architectures AAA précises avec un serveur AAA central hébergé par un opérateur, un ou plusieurs proxy AAA dans le réseau de l’opérateur même ou, aussi, dans le MANET, et des nœuds ad hoc ayant la capa- cité d’opérer des tâches d’authentification, d’autorisation et/ou de collecte. Ces solutions définissent, par ailleurs, les services commercialisables dans le cadre d’un MANET et la manière de comptabiliser leur consommation et de les fac- turer. Certaines ont aussi détaillé les protocoles d’authentification à mettre en œuvre entre les différentes parties en proposant d’étendre un protocole AAA tel que Kerberos [64] ou un protocole d’accès comme PANA [61] ou 802.1X [75]. La gestion de clés a été aussi abordée afin de pouvoir mener ces authentifications. Ainsi, l’utilisation de clés symétriques dans Kerberos a été adaptée dans [64], mais nous avons remarqué que l’emploi de couples de clés publiques/privées (à travers l’utilisation de certificats) est beaucoup plus majoritairement employé dans la littérature [62] [65] [63].
Toutefois, cette catégorie des MANETs reste dépendante, pour la majeure partie des opérations, de la présence permanente d’un opérateur. Cela risque de ne pas être toujours possible notamment lorsqu’aucun des nœuds du réseau MANET ne se trouve à proximité d’un point d’accès de cet opérateur. Dans le cas où cette situation dure assez longtemps, l’authentification d’un nœud arrivant devient alors irréalisable et ses droits d’accès aux services inapplicables. Nous avons vu que ce problème a été traité dans les solutions de la catégorie des MANETs partiellement tributaires qui mettent en œuvre des serveurs AAA dans le MANET même. Néanmoins ces solutions n’ont pas encore atteint un degré d’étude précis semblable à celui des solutions de la catégorie précédente. Lamsal„ par exemple n’a pas défini de protocole et a fait allusion à une possible adaptation du protocole Diameter étant donnée la flexibilité de celui-ci [68]. D’autre part, bien que dans WATCHMAN [69] il ait été précisé un protocole d’authentification entre deux nœuds ad hoc, l’un serveur et l’autre client, le résultat de l’authentification dépend encore de la bonne volonté de ce serveur. À supposé qu’il soit corrompu, il peut empêcher le client d’accéder à certains services auxquels il a droit. De plus, le serveur MAS centralise la tâche d’élection des SAS et les tâches de restitution des données de comptabilité à l’opérateur, ce qui pourrait le placer comme cible de choix pour certains nœuds malveillants. La corruption du MAS pourrait, par exemple, entraîner l’élection de SASs cor- rompus et complices de celui-ci ou la modification des données de comptabilité provoquant ainsi à une perte financière pour l’opérateur et/ou pour les clients et un gain pour les nœuds malveillants.
Un dernier point, qui nous semble important et qui concerne les deux catégo- ries des MANETs évoquées dans cette section, est celui de l’assurance de l’envoi et de l’intégrité des données de comptabilité : comment pouvons-nous être sûrs qu’un nœud collecteur de ces informations ait la bonne volonté de restituer ces informations, telles qu’elles, au serveur central ? La solution Sprite [66] tente d’apporter des éléments de réponses en ayant recours, dans sa démarche, à des théories économiques qui favorisent le bien-être des utilisateurs.
3.6 Conclusion 73
3.6 Conclusion
Dans le premier chapitre, nous avons étudié les concepts et les techniques de sécurité tels qu’on peut les mettre en œuvre dans le contexte d’un réseau à in- frastructure. Dans le deuxième chapitre, nous avons présenté les caractéristiques des réseaux ad hoc et mis en évidence le fait que ces solutions de sécurité de- vaient être réajustées pour tenir compte d’un contexte où la protection doit être prise en charge par les différents nœuds du réseau ainsi que par leurs organisa- tions puisque l’on ne peut plus bénéficier des protections liées à l’infrastructure. Dans ce chapitre, nous avons abordé différentes classifications d’architectures AAA et mis en évidence les solutions connues dans les cas répertoriés.
D’après les points soulevés à la section 3.5, il apparaît qu’il demeure plusieurs aspects non encore étudiés ou détaillés dans la littérature. Parmi ces éléments, nous nous sommes intéressés au problème de centralité du serveur AAA dans le cadre des MANETs partiellement tributaires. Nous chercherons, donc, dans les parties suivantes de cette thèse à résoudre ce problème grâce à la distribution du pouvoir de décision du serveur central sur plusieurs nœuds serveurs. Cela permettra d’éviter, par la même occasion, que le serveur soit un point unique de défaillance.
Deuxième partie
Conception de services AAA
distribués
Chapitre 4
Contribution : architecture,
protocoles et opérations AAA
distribués
4.1 Introduction
Dans ce chapitre, nous examinerons une proposition de solution qui par rapport aux classifications élaborée à la section 3.3 du troisième chapitre se place de la façon suivante :
1. vis à vis du modèle de dépendance, nous sommes dans un MANET partiel- lement tributaire. La majeure partie des solutions passées en revues dans le troisième chapitre étaient destinées à fonctionner en présence d’un opé- rateur. Celles qui en étaient partiellement ou complètement indépendantes manquaient de maturité, d’où l’intérêt de nous placer dans ce cadre. 2. vis à vis du modèle d’architecture, nous nous situons dans une architec-
ture hiérarchique distribuée. Ce choix découle du premier point. En effet, l’absence d’un réseau d’opérateur, même momentanée, implique l’absence du serveur AAA central de celui-ci, d’où la nécessité d’un serveur AAA dans le réseau MANET même. Mais l’étude que nous menons à la sec- tion 4.2.1 montre qu’il faut en réalité plusieurs serveurs secondés par des entités supplémentaires.
3. vis à vis des services commercialisables, notre solution AAA protège l’ac- cès aux services de routage et de contenus en supposant que tout nœud authentifié y est autorisé.
4. enfin, vis à vis du mode de communication, le deuxième point nous conduit à privilégier majoritairement un mode de communication one-to-many. La première section a pour objectif d’établir le cahier des charges des services AAA que nous souhaitons offrir dans le cadre d’un MANET partiellement tribu- taire. Les spécifications de l’architecture AAA, des protocoles qu’elle mettra en œuvre et des aspects de sécurité qu’elle doit respecter y sont en particulier pré- cisées. Afin de répondre à ces spécifications, les sections suivantes présentent nos propositions d’architecture AAA et de protocoles d’authentification et d’autori- sation. Un bref aperçu des opérations de collectes en vue d’une comptabilité est
aussi donné à la dernière section avant la conclusion. Enfin, en ce qui concerne les aspects de sécurité, ils sont traités tout au long de ces sections.
Pour suivre les tendances actuelles visant à contourner le problème de pénu- rie d’adresses IPv4, nous supposons tout au long de ce chapitre que les réseaux considérés utilisent le protocole IPv61 comme protocole de couche réseau.