Modes de communication AAA

La majorité des protocoles existants dans les solutions que l’on a recensées sont du type one-to-one18 _{qu’il s’agisse de protocoles d’authentification, d’au-} torisation ou de comptabilité. Mais Lamsal a émis l’idée de protocoles one-to many19 _{en matière d’authentification. Nous examinons ci-dessous ces deux ca-} tégories.

3.3.4.1 Protocoles one-to-one

Ce type de protocole a lieu entre un nœud ad hoc client et un serveur AAA, à travers éventuellement des entités subordonnées (cf. section 3.3.2.2), ou entre deux nœuds ad hoc l’un client et l’autre une entité subordonnée mais qui n’est pas un agent AAA comme A1, A2, A3, A1A2, A1A3 ou A2A3 (cf. paragraphe 3.2.1). Il est utilisé dans les architectures AAA hiérarchiques centrales que ce soit celles des MANETs totalement tributaires ou celles des MANETs partiellement tributaires.

MANET totalement tributaire à architecture AAA hiérarchique cen- trale La figure 3.7 représente un diagramme de séquences du processus AAA dans ce type de MANET et récapitule l’ensemble des protocoles one-to-one que l’on peut rencontrer dans la littérature. MN est un client souhaitant rejoindre le réseau pour bénéficier des services qui y sont fournis et participer à ces dif- férentes opérations, voire offrir un service comme un service de routage ou un service de contenus. R1 est son nœud voisin relayant son trafic, D est un nœud distributeur de contenus et R2 est un nœud se trouvant à la portée de la pas- serelle GW du réseau du FAI du DV. R1 tout comme D et R2 ont déjà été authentifiés et autorisés pour pouvoir jouer leurs rôles respectifs auprès du MN, tandis que ce dernier cherche à s’authentifier et à être autorisé.

Sachant que les nœuds ad hoc sont abonnés à un ou plusieurs OMS, l’étape d’initialisation se déroule de la même manière que dans les réseaux à infrastruc- ture c.-à-d. comme évoqué au paragraphe 3.2.3.1 de la section 3.2.3. Les cas particuliers de fin après départ, de révocation ou d’isolation en cas de mauvais comportement et de ré-authentification en cas d’expiration de la session n’y sont pas représentés. Lorsque MN arrive à la porté de R1 appartenant au MANET, avant toute authentification, son adresse IP doit être configurée, suite à quoi il commence à recevoir les annonces des services disponibles.

Plusieurs méthodes de configuration d’adresse IP existent, d’abord l’auto- configuration d’adresse [73] [71], ensuite l’attribution d’une adresse provisoire par R1au MN, comme suggéré par [62], enfin, la configuration par le MN d’une adresse IP générée de manière cryptographique (Cryptographically Genenerated Address ou CGA [74]) après récupération du préfixe du réseau de la part du nœud R2, comme montré dans [61]. CGA nécessite habituellement l’exécution

18. Un protocole one-to-one est un mode de communication qui implique uniquement deux entités : une première entité qui initie les échanges et une deuxième qui lui répond. Une communication entre un client et un serveur est un exemple d’une telle communication.

19. Un protocole one-to-many est un mode de communication qui implique une entité unique initiatrice des échanges et plusieurs entités réceptrices qui lui répondent. Une communication RTS/CTS (cf. section 1.4.1) est un exemple d’une telle communication : le nœud souhaitant réserver le canal envoie un RTS à tous ses voisins qui lui répondent, chacun, quand cela est possible, par un message CTS.

3.3 Taxonomie 65 MN R1 A1 D A1A2 ou A2A3 R2 AAAF GW

proxy AAA AAAF AAAH allocation d’adresse authentification établissement de clés de sessions autorisation authentification authentification établissement de clé de session

collecte (comptabilité service de contenus)

MANET

DV

DM

collecte (comptabilité service à travers Internet) service à travers Internet

service de routage

collecte (comptabilité service de routage) service de routage

collecte (comptabilité service de routage) service à travers Internet

service de contenus annonce des services

Figure 3.7 – MANET totalement tributaire à architecture AAA hiérarchique centrale : diagramme de séquences

du protocole SEND (SEcure Neighbor Discovery) [70] entre nœuds voisins, en l’occurrence ici entre MN et son voisin R1. Sargento et al. [61] propose d’étendre ce fonctionnement au delà du voisinage c.-à-d. entre MN et R2. Malheureusement les auteurs n’ont pas détaillé ce fonctionnement.

Sur la figure 3.7, nous remarquons que l’on retrouve les étapes du processus AAA classique (cf. section 3.2.3) à savoir l’authentification, l’établissement de clés de session, l’autorisation et la session autorisée où la comptabilité est ef- fectuée. Néanmoins, vu le contexte distribué d’un MANET et l’absence d’une entité centralisant les opérations du réseau, les trois étapes d’authentification, d’établissement de clés de sessions et d’autorisation ont lieu à trois niveaux dis- tincts : entre le client MN et le AAAH, entre le MN et son voisin relais R1, entre le MN et D. La première fois, l’authentification sert à établir une première rela- tion de confiance basée sur les éléments d’accréditation du MN acquis à l’étape d’initialisation. L’établissement de clés de sessions et l’autorisation servent à permettre de faire valoir ses droits futurs vis-à-vis des divers acteurs : réseau du

FAI du DV, nœuds relais et nœuds distributeurs. La deuxième fois, elles servent à établir une relation de confiance dans le voisinage afin que le R1soit assuré de l’identité du MN et de son droit au routage. Enfin, la troisième fois, elles servent à établir une relation de confiance entre le MN et D afin que celui-ci soit assuré de l’identité du MN et de ses droits d’utilisation des services de contenus qu’il propose. Notons que ce procédé suit en cela le modèle en couches d’oignon où chacun des trois acteurs évoqués présente un domaine distinct (cf. section 2.3.2 du chapitre 2).

Remarquons, par ailleurs, qu’alors que la première authentification est tou- jours présente dans la littérature, une simple autorisation peut être suffisante à la deuxième et troisième fois. Cela dépend en réalité de la manière dont la relation de confiance est définie :

– l’authentification par un serveur central seul suffit pour qu’ une relation de confiance soit établie entre le nœud nouvellement authentifié et tous les nœuds déjà présents dans le réseau. Dans ce cas, il n’y a nul besoin d’une authentification ultérieure.

– l’authentification par un serveur central seul ne suffit pas pour établir une relation de confiance avec certains nœuds comme les nœuds voisins, directement impliqués dans les opérations de routage du trafic du nœud arrivant, ou les nœuds distributeurs quand celui-ci les sollicite.

1. Protocoles entre MN et AAAH : nous en avons donné un aperçu à la sec- tion 3.3.1.1 et illustré cela à la figure 3.5. Pour effectuer concrètement l’au- thentification d’un nœud ad hoc client, DAIDALOS [61] propose d’étendre l’utilisation du protocole PANA (Protocol for carrying Authentication for Network Access) au contexte multi-saut des MANET en permettant de créer un tunnel entre ce nœud et l’EA ou le routeur d’accès. Ainsi les messages PANA se retrouvent encapsulés dans ce tunnel.

Moustafa et al. [64] proposent d’étendre le modèle d’authentification de Kerberos grâce à la médiation du proxy qui relaye les demandes d’au- thentification de chaque nœud ad hoc au serveur Kerberos. Le protocole d’authentification est à deux échanges. Le contenu des messages est le même que celui du protocole Kerberos de base quand ceux-ci circulent entre le proxy et le serveur mais il est modifié quand ils circulent entre le proxy et un nœud ad hoc. Les auteurs ajoutent en effet un drapeau à ces messages afin de distinguer ce protocole d’authentification pour nœuds ad hoc du protocole Kerberos ordinaire. En plus, dans le dernier message, TGS-REP, la structure de données autorisées est modifiée afin de délivrer plusieurs clés symétriques au MN au lieu d’une seule. Ces clés, appelées Kadhoc-auth, serviront à des authentifications ultérieures ainsi que nous le décrivons dans les deux points suivants.

En plus des clés, un ou plusieurs tickets sont aussi envoyés au MN comme éléments d’autorisation. Dans [62], AAAH envoie plutôt un identifiant, un certificat ou un jeton qui permettent au MN de faire valoir ses droits. Une adresse IP définitive est aussi envoyée pour que le MN puisse remplacer son adresse provisoire. Par la suite, R1 et R2 ajoutent une entrée pour le MN dans leurs tables respectives de nœuds authentifiés afin de s’y référer lors des prochains routages du trafic du MN. Ils peuvent par ailleurs demander une authentification supplémentaire au MN [64].

3.3 Taxonomie 67 tocole EAP-PSK pour effectuer une authentification mutuelle entre deux nœuds voisins [64].

Habituellement, le système Kerberos utilise une clé symétrique partagée entre le client et le serveur pour les opérations d’authentification. Moustafa et al. [64] proposent de se servir, de la même manière, de la clé partagée entre les nœuds ad hoc afin que deux nœuds quelconques puissent s’au- thentifier mutuellement. Mais, une clé symétrique est plus vulnérable à la divulgation qu’une clé asymétrique (cf. section 2.5 du chapitre 2). De plus, cette vulnérabilité augmente avec le nombre d’entités connaissant la même clé. Pour cette raison, les auteurs divisent le temps en N intervalles de même durée d telle qu’à chaque intervalle, une seule clé symétrique est valide et doit être utilisée par tous les nœuds20_.

Le FAI fixe un nombre n ≤ N de clés à envoyer à chaque nœud par le serveur Kerberos dans le message TGS-REP. L’intersection entre deux ensembles de clés Kadhoc-auth appartenant chacun à un nœud ad hoc distinct, dont la session est valide à la date t, est nécessairement non vide. Supposons que MN et R1 sont un tel couple de nœuds, alors ils peuvent s’authentifier mutuellement avec Kadhoc-autht.

Dorénavant, dès que MN se fera relayer son trafic, les nœuds intermé- diaires comme R1commenceront à en effectuer la comptabilité (cf. section 3.3.3.2). Par ailleurs, les services d’accès à Internet et par Internet consom- més par le MN sont aussi comptabilisés par le AAAH (cf. Figure 3.7). 3. Protocole entre MN et D : une clé Kadhoc-auth est employée par le pro-

tocole EAP-PSK pour effectuer une authentification mutuelle. Dans [62], celle-ci n’est pas nécessaire, il suffit que le MN envoie ses éléments d’auto- risation (identifiant, certificat ou jeton) à D afin que celui-ci reconnaisse ses droits. D effectue, à son tour, une comptabilité des consommations de MN en service de contenus (cf. section 3.3.3.2).

MN R1 A1A2 R2 AAA (maître ou esclave) R3 AAA (maître ou esclave) GW

proxy AAA AAAF AAAH

authentification étalissement de clé de session

MANET

DV

DM

collecte (comptabilité service d’accès au MANET) autorisation

Figure 3.8 – MANET partiellement tributaire à architecture AAA hiérarchique centrale : diagramme de séquences

20. Cette méthode est désignée par le nom de méthode de génération dynamique de clés (en anglais Dynamic key generation).

MANET partiellement tributaire à architecture AAA hiérarchique centrale WATCHMAN [69] a décrit un protocole one-to-one entre MN et un serveur AAA quelconque, maître ou esclave. Les messages de ce protocole sont relayés par R1, une entité A1A2 (cf. Figure 3.8).

MN demande l’accès au réseau. L’authentification est basée sur la crypto- graphie asymétrique (cf. section 2.4.1 du chapitre 2). R1 demande, alors, à MN sa clé publique que celui-ci lui envoie. R1 transmet cette clé au serveur AAA qui peut être maître ou esclave. Ce dernier tient à jour une base de données des utilisateurs comportant leurs clés publiques et leurs droits à la lumière de laquelle il accepte ou rejette la demande du MN. En cas d’acceptation, R1pro- cède à l’authentification du MN par un protocole question-réponse (cf. section 2.4.3.1 du chapitre 2). Si celle-ci réussit, R1fournit des éléments d’accès au MN. Ce dernier point n’a pas été détaillé. D’autre part, R1 envoie l’adresse IP du MN au serveur AAA afin que celui-ci commence les opérations de comptabilité des consommations du MN qui sont donc basées sur le temps de connexion de celui-ci.

MANET partiellement tributaire à architecture AAA pair-à-pair Le modèle de confiance dans ce type d’architecture telle que décrit par Lamsal [68] est deux-à-deux c.-à-d. qu’à chaque fois qu’un nœud serveur a accepté la demande d’accès d’un nœud client, une relation de confiance est établie entre eux deux mais pas avec le reste des nœuds ad hoc du réseau.

Toutefois le nœud serveur lui même s’était auparavant authentifié auprès d’un autre nœud serveur (cf. Figure 3.9). La confiance est ainsi en chaîne éta- blie de proche en proche. Lamsal n’a pas défini de protocole d’authentification permettant d’établir cette confiance. Néanmoins, ce mode de fonctionnement rappelle celui de Moustafa et al. [64] où des nœuds voisins s’authentifient mu- tuellement.

3.3.4.2 Protocoles d’authentification one-to-many

Nous avons rencontré ce mode de communication dans le modèle de ser- veur de groupe de Lamsal opérant dans un MANET partiellement tributaire à architecture AAA distribuée.

MANET partiellement tributaire à architecture AAA distribuée Ici encore Lamsal n’a pas défini de protocoles. Un serveur AAA consulte un groupe de nœuds avant de permettre l’accès au réseau par le client. Il émet pour cela un message vers chacun des nœuds de ce groupe qui lui répondent ensuite in- dividuellement. Si le serveur décide, à la lumière de ces réponses, que le client est autorisé à accéder au réseau, une relation de confiance entre celui-ci et tous les nœuds du réseau est alors établie. Il n’y a pas besoin d’authentifications ultérieures.