Proposition d’un handover sécurisé

AAA

Entendre le Mobile IPv6 pour effectuer des opérations commerciales à travers des domaines Administratifs, nécessite l’utilisation du Protocole AAA (Authentication, Authorisation and Accounting) [31]. Quand un utilisateur mobile doit accéder à des ressources fournies par un domaine administratif autre que son domaine mère, il doit être authentifié localement afin de s’assurer qu’il est autorisé à employer les ressources. Bien que dans les réseaux cellulaires, par exemple GSM et UMTS, la mobilité et les problèmes liés à l’utilisation de AAA sont bien résolus, ils ont toujours lieu à sa dans l’Internet. Le groupe de recherche IRTF AAAarch a proposé une architecture générique de AAA [32] afin de permettre à une grande variétée d’applications qui fonctionne dans un environnement multi domaine, d’utiliser la fonctionnalité de AAA. Dans une telle architecture, des serveurs AAA génériques sont déployés dans différents domaines, qui sont capables d’authentifier des utilisateurs, de gérer les demandes d’authentification, et de rassembler des données.
Le RFC 2977 [33] décrivent une infrastructure permettant à des serveurs AAA d’authentifier et d’autoriser les demandes de MN d’accès au réseau. Un MN appartenant à son domaine mère a besoin des ressources dans un domaine étranger en fournissant une référence à un agent local. L’agent local consulte local AAA authority (AAAL) pour prouver l’authenticité de la référence fournie à l’aide d’un canal sécurisé. L’AAAL peut ne pas avoir l’information nécessaire pour vérifier la référence, dans ce cas il contacte une autorité externe (un autre AAAL) qui est le serveur AAA mère de MN (AAAH), pour obtenir ladite information. Le protocole largement déployé du AAA est le RADIUS [34], qui a été conçu au début pour fournir une liaison point à point (PPP), mais il a certaines limitations mentionnées dans le RFC 3127 [35]. Un nouveau protocole RADIUS [36] est conçu afin fournir un les fonctionnalités de AAA pour des applications telles que l’accès de réseau ou la mobilité IP, qui sont considérés acceptable d’après le RFC 3127 [35]. On a également proposé son extension pour mobile IPv6..

Les associations de sécurité

Pour le déploiement de mobile IP dans un environnement commercial, la sécurité est primordiale.
IPsec [38] fournit les possibilités de sécuriser la communication à travers l’Internet. Un concept principal dans IPSec pour assurer l’authentification et la confidentialité est l’association de sécurité (security association), qui est un rapport à sens unique entre un émetteur et un récepteur, et offre des services de sécurité au trafic IP. Les clés secrètes d’IPSec, doivent être généré et distribuées aux entités participant dans la communication manuellement ou en utilisant des protocoles, tel que IKE [39].
Le protocole Mobile IPv6 spécifie un modèle de sécurité et exige l’utilisation d’IPsec pour protéger l’intégrité et l’authenticité des mises à jour et des acquittements [40] entre un MN et son réseau domicile voir figure 41. Les données communiquées entre l’AAAL et l’agent local peuvent être transmis via un canal sécurisé, parce qu’ils sont dans le même domaine. Il
peut également supposer l’existence d’une clé secrète permanente partagée par le MN et l’AAAH. La communication entre l’AAAL et l’AAAH peut être protégée par un canal sécurisé préétablie grâce au roaming entre les deux domaines. Pour l’association de sécurité entre le MN et HA, le Mobile IPv6 exige une gestion manuelle et permet aussi la gestion automatique de clé à l’aide du protocole IKE. Cependant, la configuration manuelle n’est pas évolutif (scalable), et IKE a besoin de d’échanges beaucoup de message entre le MN et le HA [41]. D’ailleurs, il est également difficile de préétablir l’association de sécurité entre le MN et l’agent local donc, il doit dynamiquement l’établir sur demande.

Les Méthodes d’authentifications

Dans cette section, nous discutons l’authentification et les méthodes de gestion de clé pour UMTS, WLAN et l’Internet que nous jugeons nécessaires avant de détailler l’architecture et le modèle de handover proposé.

Le réseau UMTS

UMTS réalise l’authentification mutuelle d’un utilisateur et du réseau basés sur une challenge-response et un protocole basé sur un nombre de séquence [42]. Il emploie une clé secrète permanente K, qui est partagée entre les modules User Services Identity Module (USIM) situé dans User Equipment (UE) et centre d’authentification (AuC – Authentification Center) situé dans Home Environment (HE), il est important de signaler que seulement le deux modules mentionnés ci-dessous ont accès à la clé K. Au début, International Mobile Subscriber Identity (IMSI) est envoyée de l’UE non protégé au Visitor Location Register (VLR)/Serving GPRS Support Node (SGSN) par l’intermédiaire de Radio Network System (RNS), et encore transmis au Home Location Registor (HLR) de UE. Dans HE, des vecteurs d’authentification sont générés, chaque vecteur se compose d’un nombre aléatoire RAND, d’une réponse attendue XRES, d’une clef de cryptage CK, d’une clef d’intégrité IK et d’un jeton d’authentification AUTN. Les vecteurs d’authentification sont envoyés au VLR/SGSN, RAND et AUTN d’un vecteur sont envoyés à UE. L’UE authentifie le réseau en utilisant AUTN. Si l’authentification est réussie, elle calculera une réponse RES, une clé de cryptage CK, et une clé d’intégrité IK en utilisant la clef secrète K et le RAND. L’authentification est réussite si XRES et RES de l’utilisateur sont identiques. CK et d’IK vont être envoyé au RNS pour être utiliser respectivement en tant que clé de cryptage et d’intégrité. Le processus d’authentification est détallé sur la figure 42.

L’interaction différentes méthodes d’authentification

Chacun de réseau UMTS et WLAN 802.11 possède sa propre méthode pour l’authentification et la dérivation de clé de la couche liaison de données. Pour l’accès sans fil, la sécurité de couche de liaison de données est indispensable, la raison est qu’il est particulièrement vulnérable aux attaques, ainsi la signalisation de la couche liaison de données et les données sensibles de l’utilisateur doivent être protégées. Par exemple, si la couche liaison de données n’est pas sécurisée, il est possible de lancer un déni de service, par conséquence n’importe quels mécanismes de sécurité pour les couches supérieures ne seront fonctionnels.
Tandis que le processus d’authentification d’UMTS est en fait une combinaison de la dérivation de clé et de la gestion de mobilité, ces processus sont encore séparés dans l’Internet. Le protocole de la couche réseau AAA peut être indépendant de la technologie sous-jacent de la couche liaison de données, fournit ainsi une méthode générique AAA pour interagir de divers systèmes. Si les protocoles AAA de la couche réseau sont employés pour l’accès sans fil, en plus de l’IPSec qui est exigé, la sécurisation de la couche liaison de données est également nécessaire. En principe, les clés de sécurité de la couche réseau et la couche liaison de données peuvent être dérivées dans des processus séparés, et la gestion de mobilité et les procédures d’AAA peuvent également être découplées l’un de l’autre. Mais la signalisation pour ces procédures exigera beaucoup d’accès au HA du MN, qui occupe beaucoup de la bande passante, et peut mener à une longue latence de signalisation. Une solution optimale est de combiner la gestion de mobilité avec la procédure d’AAA, et entretemps la dérivation de clés de la couche réseau et celle de la liaison de données est effectuée.

L’architecture proposée

L’architecture que nous proposons consiste à utiliser les protocoles AAA, Diameter, EAP, PANA, Mobile IPv6 et IPSec.
Dans cette section nous discutons le modèle générique d’AAA par la suite nous détaillons la méthode d’authentification et nous terminons avec la méthode de gestion de clé que nous avons proposé.

Le Modèle Général

En analysant la fonctionnalité d’AAA, les entités d’UMTS, WLAN et l’Internet montrent quelques ressemblances. Ainsi le protocole AAA pour l’accès sans fil à l’Internet dans toutesles architectures IP peut être décrit par un modèle général. En Supposant qu’un client (supplicant — dans le tableau il est désigné par A authentifié) a un contrat de service avec son réseau mère, quand il désire avoir accès à un réseau étranger, il doit être authentifié par le réseau. Les informations de l’utilisateur seront envoyées à un authentificateur local, et l’authentificateur contacte l’AAAL pour la décision d’authentification. L’AAAL peut ne pas avoir assez d’information pour authentifier le client et contactera dans ce cas l’AAAH dans le HA du client. Les entités présentes dans le modèle général, par exemple A authentifié, l’authentificateur, l’AAAL et l’AAAH chacune a sa correspondante dans les différentes technologies, conformément au Tableau 1. Il n’y a pas AAAH pour PANA et WLAN, parce que PANA considère seulement l’authentification entre l’utilisateur et le réseau d’accès, et le WLAN ne traite pas le réseau mère.

Authentification

Dans le futur scénario d’interaction de réseaux sans fil basé sur IP, les AP seront également des routeurs, par exemple, l’architecture développée par Moby Dick [46]. L’avantage de la méthode d’authentification de couche réseau est que c’est une méthode générique, qui peut être utilisée pour différentes implémentation de la couche liaison de données, et indépendantde n’importe quelle technologie de la couche liaison de données [45]. Par conséquent, elle convient au scénario d’interaction de réseaux sans fil basé sur IP. Le couplement de PANA et de Diameter peuvent fournir l’authentification de la couche de réseau; PANA est employé pour l’authentification d’accès entre un client et un authentificateur, et le Diameter est utilisé pour la communication entre les serveurs AAA et les clients. La figure 45 montre le processus d’authentification pour un MN qui est une concaténation de PANA au niveau du lien sans fil et de Diameter au niveau du réseau, tous les deux diffusent des messages EAP pour l’authentification. Quand un MN est attaché au réseau, il découvre l’agent AAA en envoyant un message PANA de découverte. Des cookies sont échangés dans les messages qui suivent, ils sont utilisés pour empêcher les attaques de genre utilisation non autorisé de ressource. Des messages EAP sont échangés entre le MN et ses serveurs AAA pendant l’authentification; EAP permet à différentes méthodes d’authentification d’être utilisées, et il est supporté par PANA et Diameter. Les messages détaillés dépendent de laméthode d’authentification choisie par le réseau. Par exemple, en utilisant l’algorithme UMTS Authentication and Key Agreement (AKA) dans les messages EAP [47], le MN et le réseau d’accès sont mutuellement authentifiés nécessitant seulement un seul accès au réseau mère. Le processus décrit ci-dessus ressemble à celle d’UMTS illustrée dans la figure 2 mais, les messages d’authentification échangés sont des messages EAP encapsulé dans des paquets IP. Les messages sont échangés sur le lien sans fil en utilisant PANA, et sur le réseau en utilisant Diameter à l’aide de l’infrastructure AAA.

Génération de clé

Les clés nécessaires pour IPSec exigé par Mobile IPv6 peuvent être dérivées en utilisant IKE. Cependant, les entités d’AAA peuvent jouer un rôle important dans la dérivation et la distribution des clés. Diameter est utilisé pour aider à la distribution des clés, celles-ci peuvent être dérivées en utilisant des nombres aléatoires ou l’algorithme de Diffie-Hellman [48]. Afin d’avoir une connexion sécurisée pour la couche liaison de données, les clés de sécurité de ladite couche doivent être dérivées. Ceci peut être réalisé en les combinant avec la dérivation des clés d’IPSec.
PANA et Diameter utilisent EAP pour envoyer les messages d’authentification, et EAP utilise une architecture hiérarchique pour les clés. L’architecture hiérarchique de clés sera bénéfique pour la dérivation de clé de la couche liaison de donnés, aussi bien que pour le handover verticale, qui sera discutée dans la prochaine section. Par exemple, la dérivation de clé basée sur des nombres aléatoires est comme suit. Après la réception de la demande d’authentification d’un MN envoyé par AAAL dans un domaine différent, l’AAAH génère deux nombres aléatoires, un pour IPSec utilisé entre le MN et HA, et l’autre pour la clé de sécurité de la couche liaison de données entre le MN et l’agent (attendant). Par la suite AAAH dérive des clés pour IPSec et de la couche de liaison de données en utilisant les deux nombres aléatoires, et partage ce secret le MN. La clé d’IPSec sera envoyée à l’HA à travers un canal sécurisé dans le réseau mère (home network) du MN, et l’HA utilise ladite clé pour dériver des clés inbound et outbound d’IPsec partagées avec le MN. Dans le message de réponse d’authentification, l’AAAH envoie à l’AAAL la clé de la couche liaison de données et deux nombres aléatoires en utilisant des messages diameter. Et l’AAAL utilisera la clé de la couche liaison de données comme une clé Master Session Key (MSK) d’EAP pour dériver une clé clef Transient Session Key (TSK) et envoie le TSK à l’agent pour compléter le cryptage. Les deux nombres aléatoires générés par l’AAAH seront également transfert dans le message de réponse d’authentification puis envoyés au MN. Le MN utilisera ces deux nombres aléatoires et la clé partagée pour dériver les clés d’IPSec avec HA, et également le MSK et le TSK.

La procédure de Handover proposée

Dans cette section nous allons décrit le handover sécurisé, au début nous discutons les prérequis pour exécuter le handover et puis nous détaillons le Fast Handover proposé.

Préambule

IPv6 mobile [40] ne traite pas la façon dont les sessions AAA peuvent être rétablies dans le nouveau réseau après handover. Afin de rétablir rapidement le contexte de service après handover, on a proposé le protocole de transfert de contexte [49] par l’IETF. Le contexte de service, comme le QoS et le contexte AAA peuvent être transférés à partir de l’ancien routeur d’accès (oAR- old Access Router) au nouveau routeur d’accès (nAR- new Access Router), ainsi le contexte de service peut être rétabli rapidement sans exiger au MN de l’établir à partir de zéro. Pour un MN l’adresse temporaire CoA dans le réseau étranger, sera utilisé avec son adresse dans le réseau mère pour assortir la politique de sécurité d’IPsec [40]. Par conséquent, après handover, l’IPSec entre le MN et HA peut rester sans changement.
Dans ce cas, le transfert de contexte est utile. Mais le transfert de contexte, particulièrement s’il est utilisé dans l’interaction entre UMTS et WLAN, a ses limitations, parce que certaine informations ne peut pas être transférée, mais devrait être plutôt renouvelées après le handover. Par exemple, dans le cas de handover entre deux technologies différents (comme notre cas : UMTS et WLAN), due aux différentes options d’accès sans fil, l’autorisation d’accès dans l’ancien réseau peut ne pas être valide dans le nouveau réseau, c’est-à-dire, un service est utilisé dans l’une de technologie d’accès peut n’est pas existé dans l’autre technologie.
Dans ce cas, avant le handover, le serveur AAA doit être consulté et la nouvelle autorisation doit être issue du nouveau réseau d’accès. En outre, le handover vertical, renouvelle les clés de sécurité pour la nouvelle couche de liaison de données, parce que celle-ci peut utiliser un algorithme de cryptage diffèrent de l’ancien. Il est également nécessaire que les nouvelles clés soient indépendantes des anciennes clés de la couche liaison de données, puisque une contrainte de sécurité pour un lien d’accès n’est pas nécessairement la même pour un autre lien.

Fast Handover

Depuis que le transfert de contexte seul ne fonctionnera pas pour le handover vertical, une signalisation est sollicitée pour le rétablissement du contexte AAA dans le nouveau réseau. Afin de réduire la latence de handover due aux mécanismes de sécurité utilisé, la nouvelle autorisation et les clés de la couche liaison de données peuvent être obtenues avant le handover. Ces mécanismes peuvent être combinés avec Fast Handover proposées par IETF [50], de sorte que seamless handover soit possible, voir figure 47.