Gestion du roaming par AAA pour les services PPP et Mobile IP

Dossier délivré pour Gestion du roaming par AAA pour les services PPP et IP par Maryline LAURENT-MAKNAVICIUS Maître de conférences Institut national des télécommunications (INT), Evry 1. Problématique... TE 7 555 2 2. Protocole de base de... 3 2.1 Format de l en-tête... 3 2.2 Format des AVP... 3 2.3 Extensions de... 4 2.4 Protocole de transport sélectionné... 4 2.5 Problèmes non résolus de... 4 3. AAA et la connexion à distance via le réseau commuté... 5 3.1 Authentification de l utilisateur... 5 3.2 RADIUS... 5 3.3 Extension NASREQ de... 6 4. AAA et la mobilité IPv4... 7 4.1 Mobilité IPv4... 7 4.2 Architecture... 7 4.3 Prérequis sur les associations de sécurité... 8 4.4 Fonctionnement du roaming... 9 4.4.1 Affectation dynamique d un agent... 9 4.4.2 Associations de sécurité... 9 4.4.3 IPv4 et la réauthentification... 10 4.5 Nouveaux messages et AVP liés à l extension de mobilité IPv4... 10 4.6 Traitement du handover... 10 5. dans les réseaux cellulaires de troisième génération 11 6. D autres utilisations possibles... 11 7. Perspectives de standardisation... 11 7.1 Protocole PANA... 11 7.2 Extension IPv6 de... 12 8. Conclusions sur les perspectives d exploitation de... 12 Bibliographie... 12 C es dernières années, les moyens de communications offerts aux utilisateurs mobiles ont fortement évolué, leur donnant la possibilité d accéder à l Internet et l Intranet de leur entreprise quelle que soit leur localisation dans le monde. Généralement, un utilisateur dispose d un accès au Réseau Téléphonique Commuté (RTC) par PPP (Point-to-Point Protocol) via un modem, en particulier s il est connecté depuis son domicile ou une chambre d hôtel. L utilisateur doit alors demander un accès au réseau auprès de son Fournisseur d Accès Internet (FAI) et doit s authentifier, en général à l aide d un mot de passe. En fonction de son type d abonnement, le FAI restreint ensuite l accès à son réseau à certains Techniques de l Ingénieur, traité Réseaux et télécommunications TE 7 555 1

GESTION DU ROAMING PAR AAA POUR LES SERVICES PPP ET MOBILE IP Dossier délivré pour services. Toutes ces vérifications sont bien entendu obligatoires pour que le FAI soit sûr d être payé pour les ressources réseau consommées par l utilisateur. Pour une gestion facilitée des abonnements, les FAI centralisent toutes les données relatives aux abonnés (mot de passe, type d abonnement, facture) dans des serveurs d accès protégé. À chaque demande de connexion, l un de ces serveurs est interrogé. Les protocoles permettant de réaliser au sein des FAI les opérations d authentification, d autorisation et de comptabilité sont dénommés AAA pour Authentication, Authorization, Accounting. Si les protocoles AAA sont particulièrement bien adaptés aux abonnés se connectant à un FAI par le RTC, il est prévu qu ils soient utilisés dans un contexte de mobilité basé sur le protocole IP. Ces deux domaines d application sont décrits dans cet article en se limitant aux aspects authentification et autorisation du AAA, c est-à-dire en laissant de côté les aspects liés à la facturation (Accounting). D autres applications naturelles du AAA sont également présentées, comme la protection de l accès Wi-Fi, les VPN... (0) Sigles 3GPP2 Third Generation Partnership Project 2 AAA Authentication, Authorization, Accounting AAP d Authentification PANA AS Association de sécurité AVP Attribute-Value Pair CDMA Code Division Multiple Access CHAP Challenge-Handshake Authentication Protocol CMS Cryptographic Message Syntax DNS Domain Name Service EAP PPP Extensible Authentication Protocol FAI Fournisseur d Accès Internet GPRS General Packet Radio Service GSM Global System for communications IETF Internet Engineering Task Force ISP Internet Service Provider NAS Network Access Server NASREQ Network Access Server Requirements OTP One-Time-Password authentication PANA Protocol for carrying Authentication for Network Access PAP Password Authentication Protocol PPP Point-to-Point Protocol RADIUS Remote Authentication Dial In User Service RNIS Réseau Numérique à Intégration de Services RTC Réseau Téléphonique Commuté SCTP Stream Control Transmission Protocol SNMP Simple Network Management Protocol TACACS Terminal Access Controller Access Control System TCP Transmission Control Protocol UDP User Datagram Protocol UMTS Universal Telecommunications System USB Universal Serial Bus VPN Virtual Private Network Wi-Fi Wireless Fidelity 1. Problématique Les concepts AAA (Authentication, Authorization, Accounting) sont apparus au début des années 1990 avec la volonté des fournisseurs FAI d offrir à leurs clients en déplacement la possibilité de se connecter à l Internet depuis le réseau commuté téléphonique (RTC). Il fallait en effet proposer une authentification fiable des utilisateurs, l authentification ne pouvant plus reposer sur la connaissance de la position géographique des utilisateurs (par exemple, numéro de téléphone). Ce service d authentification est d autant plus crucial que le système de facturation ou d accès à certains services comme le VPN (Virtual Private Network) reposent sur une bonne authentification. Pour éviter toute fraude, il est donc nécessaire que les équipements du réseau sachent mettre en œuvre les fonctions AAA, c est-à-dire : s authentifier et s identifier les uns les autres ; gérer les droits des utilisateurs mobiles ; collecter et stocker des informations sur les connexions de ces utilisateurs. Deux protocoles RADIUS et sont décrits ci-après. Le protocole AAA le plus connu est RADIUS (cf. 3) pour Remote Authentication Dial In User Service. Il est très couramment utilisé par les FAI aujourd hui mais il oblige un abonné à se connecter à son FAI de souscription, ce qui peut induire des coûts élevés. En effet, si l abonné est en déplacement à l étranger et que le FAI ne dispose pas de point d accès dans ce pays, il devra s acquitter de communications téléphoniques longue distance. Un autre protocole appelé et en cours de définition à l IETF permet de s affranchir de cette limitation en définissant des échanges inter-fai. Ainsi, sauf cas particuliers, un abonné pourra se connecter au réseau Internet ou Intranet de son entreprise au prix d une communication locale en passant par un FAI local, et ce quelle que soit sa localisation. n est cependant pas une simple évolution du protocole RADIUS utilisé dans un contexte de connexion depuis le RTC (cf. 3). Il vise également le marché des réseaux cellulaires de troisième génération où la mobilité peut être gérée par le protocole de mobilité IPv4 ([TE 7 515]). Pour cela, définit le domaine d application IPv4 (cf. 4). Il permet en particulier à des mobiles de se connecter à un réseau géré par un domaine d administration autre que le sien. Dans la suite de cet article, le protocole de base est tout d abord décrit. Les extensions de sont ensuite présentées, l une dans un contexte de connexion à distance depuis un réseau commuté par PPP (Point-to-Point Protocol) et l autre dans un environnement où la gestion de la mobilité est réalisée par le protocole de TE 7 555 2 Techniques de l Ingénieur, traité Réseaux et télécommunications

Dossier délivré pour GESTION DU ROAMING PAR AAA POUR LES SERVICES PPP ET MOBILE IP mobilité IPv4. Une réflexion est ensuite menée sur l utilisation possible de dans les réseaux cellulaires de troisième génération, voire les réseaux Wi-Fi. Enfin, sont présentés les travaux de standardisation actuels qui ne pourront que favoriser l émergence de, et quelques informations sur les perspectives d exploitation de. 2. Protocole de base de fait l objet de plusieurs documents qui, notons le, sont actuellement à l état de drafts. Le document [1] décrit le protocole de base avec le format des messages, la structure de ces messages en éléments d information appelés AVP (Attribute-Value Pair) et quelques primitives. Ce protocole de base est enrichi par des extensions (cf. 2.3) spécifiant les aspects de comptabilité [2], la possibilité de protéger les messages [3] et l utilisation de ce protocole dans les domaines d application IPv4 (cf. 4) et l accès par PPP (cf. 3). De par le découpage de en documents indépendants, il est tout à fait possible de définir d autres domaines d applications. De ce fait, apparaît comme un protocole d une grande flexibilité. 2.1 Format de l en-tête Tout message commence par l en-tête décrit à la figure 1 suivi d une liste d éléments d information AVP. Hormis le numéro de version du protocole (ici la version 1) et la longueur du message (Message length) est précisé un ensemble de drapeaux (Flags) permettant principalement de spécifier s il s agit d un message d erreur, ou si le message est une requête ou une réponse. Le code de commande (Command Code) précise le type de message transporté (plusieurs exemples sont donnés ci-après). L identifiant d application (Application-ID) indique l application à l origine de cet échange de messages ; il peut s agir d une application de comptabilité ou d une application propriétaire. Les agents étant susceptibles de lancer plusieurs requêtes d authentification par exemple, il est nécessaire qu elles puissent mettre en correspondance une requête faite avec une réponse obtenue ; c est le rôle assuré par l identifiant Hop-by- Hop. L identifiant End-to-End permet de détecter les duplications de message pour éviter que des messages ne soient traités plusieurs fois. Enfin, les AVP permettent d encapsuler des informations propres aux messages de. Version Octet 1 Octet 2 Octet 3 Octet 4 Message length Le tableau 1 donne quelques exemples de messages définis dans [1] avec leur code de commande respectif. Noter que la distinction entre un message de requête ou de réponse ne se fait pas au travers du code de commande mais par le biais du champ Flags décrit précédemment. Les messages Capabilities-Exchange sont les premiers échanges effectués entre agents ; ils leur permettent de connaître les caractéristiques d un agent comme le numéro de version utilisé, les protocoles de sécurité supportés, les applications disponibles... ; ainsi, les agents sauront s il leur est possible de communiquer entre eux. Les messages Disconnect-Peer permettent de fermer une connexion. Les messages Re-Auth permettent aux serveurs de réauthentifier/réautoriser un utilisateur/machine. Enfin, pour les échanges d informations de comptabilité, les agents disposent de messages de type Accounting. Tableau 1 Quelques messages définis dans [1] Nom de messages Command Code Accounting-Request 271 Accounting-Answer 271 Capabilities-Exchange-Request 257 Capabilities-Exchange-Answer 257 Disconnect-Peer-Request 282 Disconnect-Peer-Answer 282 Re-Auth-Request 258 Re-Auth-Answer 258 2.2 Format des AVP Les AVP sont des éléments d information de permettant de transporter des informations d authentification, autorisation, comptabilité, routage, sécurité ainsi que des informations de configuration. Le format de l en-tête d un AVP est présenté à la figure 2. Le code d AVP permet d identifier un type d AVP de façon unique. Un extrait des AVP définis est proposé dans le tableau 2. Les drapeaux AVP indiquent à un agent la façon de traiter un AVP, en particulier si son traitement est facultatif ou obligatoire. Le champ optionnel Vendor-ID permet d identifier le constructeur à l origine de cet AVP propriétaire, la présence de ce champ étant indiquée par un drapeau du champ AVP Flags. Le champ Data précise les informations transportées dans l AVP. (0) Flags Command Code Octet 1 Octet 2 Octet 3 Octet 4 Application-ID AVP Code Hop-by-Hop Identifier End-to-End Identifier AVP Flags Vendor-ID (opt) AVP Length AVP(s) (longueur variable) Data (longueur variable) Figure 1 En-tête d un message Figure 2 En-tête d un AVP Techniques de l Ingénieur, traité Réseaux et télécommunications TE 7 555 3

GESTION DU ROAMING PAR AAA POUR LES SERVICES PPP ET MOBILE IP Dossier délivré pour (0) Tableau 2 Quelques AVP définis dans [1] Nom des AVP AVP Code User-Name 1 Result-Code 268 Session-Id 263 Auth-Request-Type 274 Re-Auth-Request-Type 285 Authorization-Lifetime 291 Relais 1 IPsec IPsec TLS Relais 2 Client Extension sécurité de Noter que les 256 premières valeurs du champ AVP Code sont réservées pour préserver la compatibilité avec le protocole RADIUS tandis que les valeurs suivantes sont utilisées par et ses extensions. En particulier, comme le montre le tableau 2, l AVP User- Name contenant l identifiant de l utilisateur est issu de RADIUS et porte le numéro de code 1. De nombreux autres AVP sont définis comme Result-Code présent dans la plupart des messages de réponses pour préciser si la demande a été satisfaite ou si une erreur particulière s est produite. L AVP Session-Id identifie de façon unique une session d un utilisateur. L utilité des AVP suivants sera décrite aux paragraphes 3.3 et 4.4.3. 2.3 Extensions de comprend actuellement quatre extensions qui définissent chacune leurs propres AVP. Les extensions liées aux domaines d application IP et l accès par PPP étant décrits plus loin ( 3 et 4), ce paragraphe se limite à la description des extensions de sécurité et de comptabilité. L extension sécurité de [3] permet de protéger les échanges de messages entre deux agents. Cette protection assure la confidentialité des messages et garantit à l agent récepteur que le message reçu est intègre et que l origine du message est authentifiée. Plus précisément, certains AVP peuvent être chiffrés dans des AVP appelés CMS-Encrypted- Data AVP ; ils peuvent être protégés en intégrité et authentifiés par l ajout d un AVP contenant une signature et appelé CMS-Signed- Data AVP. Les AVP cryptographiques sont exprimés dans la syntaxe CMS (Cryptographic Message Syntax) avant d être encapsulés dans ces AVP. Pour tous les aspects liés à la cryptographie et aux notions de services de sécurité, se reporter à l article [H 5 210]. Pour rendre l ensemble des services de sécurité mentionnés ciavant, il est nécessaire que les agents partagent une association de sécurité. La mise en place de cette association de sécurité est décrite dans [3], avec le type de cryptographie symétrique ou asymétrique préconisée en fonction des services de sécurité. L usage de l extension sécurité est particulièrement intéressant pour les communications entre client et serveur localisés dans des domaines d administration différents (par exemple, opérateur ou FAI). En effet, il est prévu dans ce cas-là que les messages puissent transiter par des relais. Pour éviter que des informations confidentielles échangées dans les messages ne soient divulguées, voire modifiées, la protection des AVP doit être réalisée au sein même des messages. En effet, d autres moyens de protection existent comme les protocoles IPsec [TE 7 545] et TLS [H 5 230] ; ces protocoles peuvent servir à protéger les échanges entre agents directement en communication comme le montre la figure 3 ; dès lors qu un ou plusieurs relais intermédiaires interviennent, les relais ont accès au contenu des messages ; de ce fait, il peut être intéressant de protéger le contenu même de ces messages par l extension sécurité de. Figure 3 Protocoles de sécurité utilisés entre agents pour protéger leurs échanges L extension de comptabilité est commune à tous les domaines d application existants et à ce titre est décrit dans le même document que le protocole de base [1]. Elle sert à la collecte d informations pour tout type d applications de comptabilité. Toute la difficulté de cette extension est de définir des AVP de comptabilité qui conviennent aux applications de comptabilité existantes [4] malgré la multiplicité des protocoles de comptabilité (RADIUS, TACACS+, SNMP) et des formats de données collectées mis en jeu [2]. 2.4 Protocole de transport sélectionné Le choix du protocole de niveau transport a une grande importance. En effet, le bon acheminement des messages en dépend. Pour RADIUS par exemple, le choix s est porté sur le protocole UDP (User Datagram Protocol) qui est réputé pour son manque de fiabilité ; en effet, il ne prévoit aucun mécanisme de retransmission de paquets en cas de perte ; ce problème est particulièrement sévère en comptabilité puisque la perte de messages RADIUS se traduit directement par une perte de revenu pour le FAI ou l opérateur concerné, la collecte d informations de comptabilité par le serveur RADIUS ne pouvant plus se faire. Pour, le choix s est porté sur les protocoles de transport fiables TCP (Transmission Control Protocol) et SCTP (Stream Control Transmission Protocol) [5]. Grâce à leurs mécanismes de reprise sur erreur, TCP et SCTP garantissent le bon acheminement des messages. Cependant, SCTP apparaît mieux adapté aux échanges du fait qu il réagit plus promptement en cas de disfonctionnement d équipement réseau ou terminal [6]. Le protocole TCP étant beaucoup plus répandu que SCTP, il a été décidé que les clients utilisent préférentiellement SCTP, mais qu en cas d indisponibilité, TCP devait être employé. Quant aux serveurs, ils doivent supporter les deux protocoles TCP et SCTP [6]. La tendance future sera bien entendu de donner la préférence à SCTP. 2.5 Problèmes non résolus de Tel que le protocole est défini aujourd hui, il est impossible que des équipements de réseau découvrent de façon dynamique le positionnement de serveurs AAA car aucun protocole n a été défini ou modifié pour supporter cette fonctionnalité. Il en résulte la contrainte que les équipements faisant appel à des serveurs AAA doivent être informés statiquement du positionnement de ces serveurs. TE 7 555 4 Techniques de l Ingénieur, traité Réseaux et télécommunications

Dossier délivré pour GESTION DU ROAMING PAR AAA POUR LES SERVICES PPP ET MOBILE IP (1) PAP Authenticate Request Username, PAP_Password Utilisateur (4) PAP Authenticate Ack ou PAP Authenticate Nak NAS Figure 4 Authentification par PAP (2) Access Request Username, PAP_Password (3) Access Accept ou Access Reject 3. AAA et la connexion à distance via le réseau commuté Lorsqu un utilisateur veut accéder au réseau Internet, voire à l Intranet de son entreprise depuis un réseau commuté (de type RTC, RNIS, GSM ou GPRS), il doit brancher un modem entre son ordinateur et le réseau commuté. Il compose alors un numéro de téléphone spécifique fourni par son Fournisseur d Accès Internet (FAI). Ce numéro lui donne accès à un équipement de son FAI appelé NAS (Network Access Server). Pour accéder en tant que particulier à l Internet, il devra se connecter sur son propre FAI de souscription. S il veut accéder à son Intranet, il devra contacter le FAI de souscription de son entreprise qui l identifiera alors comme l employé d une certaine entreprise cliente. Tous les échanges entre le NAS et le modem sont réalisés par le protocole PPP (Point-to-Point Protocol) [7] qui assure le transport de paquets IP au travers d une liaison téléphonique par encapsulation. Le NAS est situé à la frontière entre le réseau commuté et le FAI ; sa configuration, voire sa gestion sont classiquement assurées par le FAI. Le NAS a pour rôle de contrôler l identité de l utilisateur requérant un accès au réseau du FAI et de vérifier que sa requête est autorisée. Différentes techniques exploitées par PPP pour authentifier un utilisateur (PAP, CHAP, EAP) sont décrites dans le paragraphe 3.1. Le NAS ne disposant pas des informations permettant de mener à bien l authentification peut faire appel à deux solutions AAA au choix. Soit il contacte un serveur RADIUS (cf. 3.2) ; c est la solution actuellement déployée. Soit il fait appel à l infrastructure (cf. 3.3) ; c est la solution qui tend à remplacer RADIUS. 3.1 Authentification de l utilisateur RADIUS Lors de l établissement d une session PPP avec le NAS, l utilisateur doit s authentifier auprès du NAS [H 5 520] généralement en se basant sur le protocole PAP (Password Authentication Protocol) ou CHAP (Challenge-Handshake Authentication Protocol) [8]. Pour une authentification par PAP (figure 4), l utilisateur doit fournir un login (Username) et un mot de passe (PAP_Password). Pour CHAP (figure 5), le NAS doit générer un nombre aléatoire (Challenge) et le communiquer à l utilisateur ; l utilisateur doit alors retourner son login (Username) et une chaîne de caractères (CHAP_Result) qui est fonction du login, du mot de passe et du nombre aléatoire. Pour vérifier la validité de ces paramètres d authentification, le NAS les transmet à une infrastructure AAA de type RADIUS ou dont les traitements sont décrits plus loin ( 3.2 et 3.3). Le protocole PAP souffre d une grande sensibilité aux écoutes qui pourraient être réalisées sur le RTC. En effet, les mots de passe récupérés peuvent être réutilisés par un espion pour usurper l identité d un utilisateur légitime. PAP a été amélioré grâce à l émergence (1) CHAP Challenge Challenge Utilisateur NAS (2) CHAP Response Username, CHAP_Result (4) CHAP Success ou CHAP Failure Figure 5 Authentification par CHAP des systèmes de mots de passe à usage unique appelés classiquement OTP pour One Time-Password authentication. Ces techniques OTP nécessitent que l utilisateur dispose d un équipement annexe (par exemple : token USB, SecurID) capable de générer un nouveau mot de passe pour chaque nouvel établissement de session PPP [9]. Dans la pratique, lorsque l utilisateur se voit demander un mot de passe, il rentre son code pin sur son équipement annexe (par la suite : son token), ce qui en déverrouille l accès. Le token fournit alors automatiquement un mot de passe sous la forme d une chaîne de caractères. Ce mot de passe dynamique a une durée de validité limitée classiquement symbolisée par un sablier. C est ce mot de passe qui doit être rentré par l utilisateur lors de l authentification PAP. La génération de ce mot de passe peut dépendre de l heure universelle, d un compteur, d une série de nombres, etc. Il est bien entendu indispensable que le token soit parfaitement synchronisé avec un serveur d authentification forte qui sera sollicité lors de la vérification du mot de passe. Les constructeurs s intéressant à la technologie OTP, commercialisent donc à la fois les token (à fournir en autant d exemplaires que d utilisateurs) et un serveur d authentification forte. Pour s affranchir de l évolution des protocoles d authentification, l IETF a défini un protocole d authentification générique pour PPP appelé EAP (PPP Extensible Authentication Protocol) [10]. EAP n est rien d autre qu un protocole d encapsulation ; il intervient une fois la session PPP établie (après les échanges de signalisation PPP, en tant que premières données échangées) et de ce fait, il peut supporter n importe quel mécanisme d authentification. 3.2 RADIUS (3) Access Request Username, CHAP_Result, Challenge (3) Access Accept ou Access Reject RADIUS Le protocole RADIUS (Remote Authentication Dial-In User Service) [11] a été défini dans les années 1990 pour faciliter l authentification des utilisateurs dans un réseau. L idée consiste à centraliser les paramètres d authentification des utilisateurs (par exemple login/mots de passe) dans un serveur couramment appelé serveur RADIUS. Pour authentifier un utilisateur, un équipement de réseau, par exemple un NAS, doit transmettre au serveur RADIUS les paramètres d authentification fournis par l abonné (cf. 3.1) sous la forme d une requête Access Request du protocole RADIUS (cf. figures 4 et 5). Si ces paramètres aboutissent à une authentification réussie de l utilisateur, le serveur RADIUS du FAI retourne alors une réponse d acceptation Access Accept, sinon il retourne une réponse d échec Access Reject. À noter que pour le protocole CHAP (figure 5), le NAS doit fournir au serveur RADIUS l ensemble des paramètres permettant de mener à bien l authentification. Ces paramètres comprennent bien évidemment le login de l utilisateur (Username), le résultat retourné par l utilisateur (CHAP_Result), mais également le nombre aléatoire initialement fourni par le NAS (Challenge). En fait, le rôle du NAS consiste tout simplement à traduire des requêtes d authentification PAP ou CHAP en requêtes RADIUS et inversement pour les réponses. Techniques de l Ingénieur, traité Réseaux et télécommunications TE 7 555 5

GESTION DU ROAMING PAR AAA POUR LES SERVICES PPP ET MOBILE IP Dossier délivré pour Le NAS et le serveur RADIUS doivent partager une association de sécurité, ce qui leur permet d authentifier leurs échanges RADIUS et de chiffrer les paramètres d authentification fournis par un abonné. Ainsi, en cas d écoutes sur le réseau du FAI, il ne sera pas possible, à partir des messages RADIUS espionnés, de prendre connaissance du mot de passe PAP d un utilisateur (cf. 3.1). Le rôle du serveur RADIUS ne se limite pas seulement à authentifier un utilisateur. Il permet aussi de gérer de façon dynamique des plages d adresses IP disponibles au sein du FAI. Ainsi, une fois l abonné authentifié, le serveur RADIUS communiquera une adresse IP locale allouée à l équipement de l abonné, ainsi qu un certain nombre d autres paramètres indispensables à la configuration de la carte réseau de l équipement (adresse du serveur DNS, etc.). Grâce à cette adresse, l abonné sera en mesure d émettre et de recevoir des paquets IP. Le serveur RADIUS a également le rôle fondamental de collecter des informations liées aux connexions des utilisateurs. En particulier, il est chargé d enregistrer la durée de connexion, voire le nombre de paquets émis/reçus, ce qui est habituellement employé à des fins de facturation par le FAI. RADIUS a l avantage de permettre au serveur RADIUS de communiquer au NAS des règles de filtrage, ce qui permet de restreindre l accès d un utilisateur mobile à quelques services par exemple. Ainsi, il est tout à fait possible, en fonction de l abonnement souscrit, d interdire l accès à certains services. C est le NAS qui se chargera de filtrer les paquets IP. Grâce à sa simplicité, RADIUS est largement utilisé aujourd hui par les FAI, mais aussi par les entreprises pour authentifier leurs employés dans le cadre des VPN nomades (c est-à-dire lorsque des employés en déplacement ou depuis chez eux veulent établir un tunnel avec le site de leur entreprise). Le principal inconvénient de RADIUS est d obliger un utilisateur à se connecter à son FAI de souscription, les autres FAI n étant pas capables de l authentifier. Il risque d en résulter des factures de communication élevées. En effet, un utilisateur en déplacement à l étranger qui se trouve éloigné d un point d accès de son FAI ne pourra pas faire appel au FAI local et devra donc payer une communication longue distance. C est ce problème auquel permet de répondre l extension NASREQ de. 3.3 Extension NASREQ de L extension NASREQ (Network Access Server Requirements) de [12] permet de répondre aux insuffisances de RADIUS et de permettre à des utilisateurs mobiles d accéder à l Internet en se connectant à n importe quel FAI. Cette extension permet à différents domaines d administration (FAI, opérateurs de réseau cellulaire GSM, GPRS...) de collaborer de façon à authentifier des utilisateurs, les autoriser à accéder à différents services en fonction de leur contrat de souscription et enfin pour échanger des informations de comptabilité. L architecture définie dans est décrite à la figure 6 et fait apparaître deux domaines d administration et avec deux serveurs correspondants. Au lieu d interroger un serveur RADIUS, le NAS interroge le serveur, qui, dans certains cas, peut procéder localement à une authentification et répondre directement au NAS, mais qui peut aussi relayer la demande auprès d un serveur. Pour identifier le serveur, le serveur analyse l identificateur de réseau d accès [13] fourni par le mobile qui se présente classiquement sous la forme utilisateur@domaine_mere. Noter que le NAS joue le rôle d un client tel que défini au paragraphe 2.3. Comme le décrivent la figure 7 et le tableau 3, l extension NASREQ définit deux messages AA-Request et AA-Response qui correspondent à la valeur 265 du champ Command-Code. Pour faciliter la migration de RADIUS vers, les 256 premières valeurs du champ AVP Code des AVP de sont réservées à celles de RADIUS (cf. 2.2). Dans l extension NASREQ, les AVP issus de RADIUS sont très peu exploités, mais l avantage est de pouvoir sans difficulté implémenter un agent de traduction de protocoles entre RADIUS et. Tableau 3 Les deux nouveaux messages définis pour NASREQ [12] Nom des messages Command Code AA-Request 265 AA-Answer 265 (0) Réseau commuté (RTC, GSM, GPRS ) Domaine d'administration (FAI, opérateur ) Domaine d'administration (FAI, opérateur ) (3) AA-Request (4) AA-Response NAS (2) AA-Request (5) AA-Response NAS Client : machine IPv4 qui est amenée à se déplacer : serveur du domaine chargé de gérer les utilisateurs de son domaine d'administration, de les authentifier et de délivrer des autorisations à la demande du serveur (1) Request (6) Response Protocol : serveur du domaine qui relaie les demandes d'authentification issues d'un NAS local au serveur approprié Figure 6 Architecture de l application NASREQ de Utilisateur Protocol PPP Figure 7 Messages NASREQ échangés lors de l accès par PPP d un utilisateur à un FAI TE 7 555 6 Techniques de l Ingénieur, traité Réseaux et télécommunications

Dossier délivré pour GESTION DU ROAMING PAR AAA POUR LES SERVICES PPP ET MOBILE IP NASREQ est plus flexible que RADIUS sur bien des aspects, ce qui n est pas sans introduire de réels problèmes d interopérabilité avec RADIUS. Dans NASREQ, contrairement à RADIUS, il est possible d autoriser un utilisateur à se connecter sans pour autant l authentifier ; de même, il est possible d authentifier un utilisateur sans vérifier qu il dispose des autorisations requises et enfin les deux opérations peuvent être réalisées simultanément. Pour les deux premiers cas, la requête AA-Request doit contenir l AVP Auth- Request-Type indiquant AUTHORIZE_ONLY, AUTHENTICATE_ONLY, le dernier cas étant le mode préconisé par défaut (AUTHORIZE_AUTHENTICATE). Il est également possible pour un serveur de réauthentifier et/ou réautoriser un utilisateur en cours de connexion. Pour cela, le serveur doit, lors de la première authentification, spécifier le temps maximal permis avant la réauthentification/ réautorisation de l utilisateur, et préciser s il s agit d une authentification, une autorisation ou les deux. Pour cela, deux AVP ont été définis : Authorization-Lifetime pour préciser la durée et Re-Auth- Request-Type pour indiquer le type de tests (authentification et/ou autorisation) à faire sur les requêtes des utilisateurs. suit aussi les évolutions de RADIUS. En particulier, le protocole d authentification générique EAP introduit dans RADIUS (cf. 3.1) est actuellement en cours d adaptation à [14]. 4. AAA et la mobilité IPv4 La mobilité des utilisateurs dans un réseau peut être gérée par le protocole de mobilité IPv4 [TE 7 515] pour peu que les mobiles disposent du logiciel de mobilité IPv4. Dès lors que le mobile quitte son domaine d administration, il est intéressant que son accès au domaine soit sécurisé par le protocole [15]. L extension IP de [15] [16] s avère particulièrement intéressante pour les réseaux cellulaires de troisième génération de type CDMA (le projet 3GPP2 (Third Generation Partnership Project 2) est chargé de la définition des spécifications correspondantes [18]) puisque les pays nord-américains et asiatiques s appuient sur le protocole de mobilité IPv4 pour gérer la mobilité. Dans le cadre de ces réseaux cellulaires, l extension IP de permettrait aux domaines d administration (FAI, opérateur) d authentifier et autoriser des mobiles à se connecter, mais surtout de prendre en charge les aspects comptabilité. Notez que l extension IP n est pas limitée aux réseaux cellulaires de troisième génération. Rien n empêche des industriels de gérer eux-mêmes la mobilité de leurs personnels et d utiliser pour authentifier, autoriser et obtenir des informations sur la durée de connexion, mais à titre purement informatif (et non dans un but de facturation). 4.1 Mobilité IPv4 Le protocole de mobilité IPv4 ( IP en anglais) [TE 7 515] [17] est un protocole qui permet à un mobile d être joint et lui-même de communiquer (avec d autres mobiles ou terminaux fixes) quelle que soit sa position géographique. Pour une description détaillée de la mobilité IPv4, le lecteur se reportera à [TE 7 515]. Cependant, pour une meilleure compréhension de cet article, certains points sont précisés ci-après, en particulier les aspects liés à la sécurité. Pour rappel, un mobile est doté de deux adresses : une adresse principale ou qui permet d identifier le mobile de façon unique et qui correspond à son adresse IP de rattachement dans son réseau lorsque le mobile n est pas en déplacement ; une adresse temporaire qui permet de localiser un mobile en déplacement dans un réseau et de lui adresser des paquets. AS2 Figure 8 Associations de sécurité prépartagées dans le cadre de la mobilité IPv4 Un routeur particulier appelé agent situé dans le réseau est chargé de gérer la mobilité d un ensemble de mobiles appartenant à son domaine d administration. Pour cela, un mobile parti en déplacement doit émettre un message de demande d enregistrement à son agent lui précisant son adresse temporaire. L agent enregistre à ce moment-là l association entre les adresses principale et temporaire du mobile et retourne un message de réponse d enregistrement. Ces messages peuvent être relayés par un routeur du réseau appelé agent qui peut, lui aussi, enregistrer l association d adresses. Une fois l enregistrement réalisé, l agent a alors la charge de transmettre via un tunnel IP tous les paquets destinés au mobile à son adresse temporaire. Il est capital que les messages d enregistrement soient authentifiés pour éviter des détournements de trafic fâcheux. En effet, sans aucune protection, il serait facile, pour un hacker, de forger de faux messages de demande d enregistrement avec une adresse temporaire bien choisie de telle sorte que tout le trafic destiné au mobile usurpé soit dirigé vers une des machines du hacker. Dans le protocole de mobilité IPv4, les messages de demande et de réponse d enregistrement sont authentifiés par des extensions spécifiques de ce protocole appelées dans [TE 7 515] des en-têtes d authentification. Plus exactement, le mobile et l agent sont tenus d authentifier l origine de ces messages. L authentification étant basée sur de la cryptographie symétrique [H 5 210], il est nécessaire qu ils conviennent au préalable d une association de sécurité (AS1 de la figure 8). Optionnellement, l agent peut partager deux associations de sécurité AS2 et AS3 avec le mobile et l agent de telle sorte que tous ses échanges avec le mobile et avec l agent puissent être authentifiés. La mobilité IPv4 apporte une évolution conceptuelle du nomadisme car elle se base sur des mécanismes de redirection de paquets. En effet, une connexion classique à Internet (telle que traitée par l extension NASREQ) oblige le mobile à tirer à lui l information disponible dans son Intranet, par exemple dans sa messagerie électronique. Avec la mobilité IPv4, c est le réseau qui pousse le trafic vers la position courante du mobile. De ce constat, la mobilité IPv4 peut s avérer intéressante en particulier pour les applications temps réel comme la voix sur IP (VoIP), la vidéoconférence... où la présence immédiate de l utilisateur est nécessaire. 4.2 Architecture AS3 AS1 Association de sécurité optionnelle Association de sécurité obligatoire L architecture retenue pour dans un contexte de mobilité s appuie sur celle de la mobilité IPv4. Comme le présente la figure 9, elle inclut un agent et un agent, et définit deux serveurs : Techniques de l Ingénieur, traité Réseaux et télécommunications TE 7 555 7

GESTION DU ROAMING PAR AAA POUR LES SERVICES PPP ET MOBILE IP Dossier délivré pour Domaine d'administration Domaine d'administration : machine intégrant le code de mobilité IPv4 et amenée à se déplacer : routeur IPv4 du domaine chargé d'enregistrer la position courante du mobile en déplacement de manière à lui transmettre tout le trafic IP qui lui est destiné : serveur du domaine chargé d'authenfier un mobile et d'autoriser un mobile à s'enregistrer auprès d'un agent spécifique local ; il peut distribuer des clés aux différentes entités intervenant dans pour protéger les échanges entre les différentes entités : routeur IPv4 du domaine qui gère les mobiles en déplacement dans son domaine et relaie les demandes d'enregistrement en provenance du mobile vers le serveur : serveur du domaine qui relaie les demandes d'authentification issues d'un agent relais au serveur approprié Figure 9 Architecture de l application IP de un serveur et un serveur. Une autre entité appelée broker peut également intervenir pour servir d intermédiaire entre les serveurs afin de les mettre en relation de façon sûre (cf. 4.3). Les agents et relais dans le cadre de ne tiennent pas exactement le même rôle que dans la mobilité IPv4. L agent peut être affecté dynamiquement à un mobile par le serveur. Cela signifie que le mobile est authentifié par le serveur et non l agent. À ce titre, c est l association de sécurité AS4 (figure 10) entre le mobile et le serveur qui est obligatoire, l association AS1 étant construite lors des échanges ultérieurs (cf. 4.4.2). AS6 AS3 AS7 AS5 4.3 Prérequis sur les associations de sécurité AS4 Étant donné l enjeu des fonctions rendues par, en particulier les aspects comptabilité, tous les échanges sont authentifiés et certaines informations sont chiffrées. De nombreuses associations de sécurité doivent donc être partagées au préalable entre les entités de l architecture de. Ces associations apparaissent en trait plein sur la figure 10. En particulier, le mobile doit partager une association de sécurité AS4 avec son serveur pour que ce dernier puisse l authentifier. En interne à chaque domaine d administration, les agents / et leurs serveurs respectifs doivent partager une association de sécurité qui est référencée sur la figure 10 par AS5 et AS6. Il est aussi capital que les domaines d administration et s authentifient mutuellement pour éviter par exemple que certaines factures restent impayées ou que de fausses factures soient émises par l un des domaines. Le grand nombre de domaines d administration potentiels rend quasi impossible l établissement d associations de sécurité AS7 entre chaque paire de serveurs. C est pourquoi, il est préconisé de définir un broker qui partage AS2 AS1 Association de sécurité prépartagée Association de sécurité optionnelle Association de sécurité mise en place au cours des échanges Figure 10 Associations de sécurité dans le cadre de l extension IP de une association de sécurité avec le serveur de chaque domaine d administration. C est lui qui mettra en relation les domaines d administration de façon sûre en certifiant aux serveurs TE 7 555 8 Techniques de l Ingénieur, traité Réseaux et télécommunications

Dossier délivré pour GESTION DU ROAMING PAR AAA POUR LES SERVICES PPP ET MOBILE IP l identité de l autre. C est-à-dire, soit le broker permettra aux serveurs de construire une association de sécurité commune et les serveurs communiqueront sans intermédiaire, soit le broker sera sollicité à chaque échange de messages et devra relayer le trafic d un serveur à l autre. Notez que contrairement au modèle de sécurité préconisé dans la mobilité IPv4 (figure 8), le mobile ne partage pas d associations de sécurité avec l agent mais avec le serveur (figure 10). Ce sont les échanges qui lui permettront de construire une association de sécurité avec un agent (cf. 4.4.2). 4.4 Fonctionnement du roaming L extension IPv4 de a été définie avec la volonté d éviter des modifications trop importantes du code lié au protocole de mobilité IPv4. C est pourquoi, l extension IPv4 de ne modifie pratiquement pas le traitement dans le mobile. Le mobile doit toujours construire un message de demande d enregistrement comme pour la mobilité IPv4, mais il doit ajouter une extension MN-AAA contenant de quoi permettre au serveur d authentifier le mobile ; il peut également ne pas préciser d adresse principale ou d adresse d agent, auxquels cas ce sera son domaine qui lui affectera ces adresses. Comme le montre la figure 11, le mobile émet le message (1) de demande d enregistrement IPv4 sur le réseau avec l extension MN-AAA de IPv4. L agent intercepte le message, encapsule la demande d enregistrement (Registration Request) dans l AVP MIP-Reg-Request, recopie l extension MN-AAA dans l AVP MIP-MN-AAA-Auth, forme le message AA- -Node-Request (2), et l envoie à son serveur. Notez que l agent sert en fait d interface entre le mobile et l architecture ; il utilise l infrastructure afin d authentifier et autoriser le mobile à se connecter. Le serveur ne disposant généralement pas des informations lui permettant d authentifier le mobile, transmet le même message (3) au serveur. Pour identifier le serveur d appartenance du mobile, il analyse l identificateur de réseau d accès [13] indiqué par le mobile qui apparaît sous la forme utilisateur@domaine_mere. Le serveur authentifie la provenance du message en fonction du contenu des AVP MIP-MN-AAA-Auth et MIP-Reg- Request (3) et vérifie que le mobile est autorisé à se connecter. Si besoin est, il peut également affecter un agent au mobile de façon dynamique ; il peut aussi attribuer une adresse principale au mobile. Il construit ensuite le message Home--MIP-Request (4) qui encapsule la demande d enregistrement du mobile (dans l AVP MIP-Reg-Request), ainsi que, optionnellement, l adresse principale nouvellement affectée au mobile (dans l AVP MIP--Node- Address). L agent vérifie la validité du message, récupère la demande d enregistrement et fait appel à son logiciel de mobilité IPv4 pour traiter cette demande émanant du mobile. Si le mobile ne dispose pas d adresse principale et le serveur n en a pas alloué une, l agent en affecte une lui-même au mobile. Il construit la réponse d enregistrement IPv4 (Registration Reply) et encapsule toutes ces informations dans les MIP-Reg-Reply et MIP--Node-Address dans le message Home--MIP- Answer (5). Ce message parvient par le biais du message AA- -Node-Answer à l agent (6) et (7) qui récupère par décapsulation la réponse d enregistrement (Registration Reply) de mobilité IPv4 et la restitue au mobile (message (8)). Une fois que ces échanges sont effectués, les agents et et le mobile interviennent comme dans un contexte de mobilité IPv4 classique. Les agents interviennent pour renouveler les associations de sécurité ou pour procéder à une nouvelle authentification (cf. 4.4.3). 4.4.1 Affectation dynamique d un agent Grâce à l extension IPv4 de, il est possible d affecter dynamiquement un agent au mobile, et même d en affecter un dans le domaine. Pour cela, le mobile doit indiquer par des adresses spécifiques d agent s il souhaite disposer d un agent exclusivement dans son domaine (adresse 255.255.255.255) ou si la localisation d un agent dans son domaine ou son domaine lui est indifférente (adresse 0.0.0.0). Dans ce dernier cas, le serveur doit préciser au serveur dans le message (3) de la figure 11 ses capacités à affecter un agent (AVP MIP-Feature-Vector) et éventuellement l identité d un agent potentielle dans le domaine (AVP MIP-Candidate-Home--Host). C est ensuite au serveur de décider de l agent à affecter au mobile en fonction de sa politique de sécurité locale. Si un agent est alloué dans le domaine, alors les messages (4) et (5) sont émis par le serveur vers le serveur qui sert de relais pour joindre le nouvel agent affecté. Noter que le serveur ne connaissant pas a priori cet agent, l association de sécurité AS5 est inexistante. C est-à-dire, seul le serveur partage une association de sécurité avec l agent. 4.4.2 Associations de sécurité Au cours des échanges, les agents doivent mettre en place les associations de sécurité AS1, AS2 et AS3 (figure 10) si elles sont inexistantes, et en particulier des clés de chiffrement. L association AS1 entre le mobile et l agent est très importante car elle sert dans le protocole IPv4 à l agent pour authentifier les messages IPv4 permettant l enregistrement des déplacements du mobile. En cas d inexistance de AS1, le serveur se doit de communiquer les paramètres AS1 au mobile et à l agent de façon confidentielle. Si l agent est situé dans le domaine (cas présenté à la figure 10), le serveur peut communiquer directement AS1 en l encapsulant dans l AVP MIP-HA-to-MN-Key dans le message (4), la protection en confidentialité de cet AVP pouvant être assurée par l association de sécurité AS5 et l extension sécurité (cf. 2.3). Si l agent appartient au domaine, la communication de AS1 est plus difficile puisque le serveur ne connaît pas l agent et ne partage donc pas d association de sécurité avec lui ; la protection sera en fait assurée en deux temps d abord entre les serveurs et grâce à AS7 (éventuellement via le broker), et ensuite entre le serveur et l agent local grâce à une autre association de sécurité préalablement établie. Pour communiquer AS1 au mobile, la difficulté est de faire dialoguer le serveur avec le mobile, le serveur n utilisant que le protocole et le mobile que le protocole IPv4. L idée est donc que le serveur encapsule AS1 dans le message (4) dans l AVP MIP-MN-to-HA-Key, l AVP étant protégé par AS4. L agent va encapsuler cet AVP dans le message de réponse d enregistrement (Registration Reply) dans une extension IPv4. Ainsi, l AVP MIP-Reg-Reply qui parviendra à l agent puis au mobile contient les paramètres AS1 protégés avec AS4. Les autres associations AS2 et AS3 suivront des traitements similaires. Elles nécessitent toutefois la définition des AVP suivants : MIP-FA-to-MN-Key, MIP-MN-to-FA-Key, MIP-HA-to-FA-Key et MIP-FAto-HA-Key. Pour éviter d utiliser sur une trop longue durée une association de sécurité, ce qui amoindrirait le niveau de sécurité global, il est nécessaire de spécifier une durée de vie maximale pour l association. Cette durée de vie est renseignée par l AVP MIP-Key-Lifetime. Techniques de l Ingénieur, traité Réseaux et télécommunications TE 7 555 9

GESTION DU ROAMING PAR AAA POUR LES SERVICES PPP ET MOBILE IP Dossier délivré pour (3) AA--Node-Request (Registration Request) (6) AA--Node-Answer (Registration Reply) (2) AA-- Node-Request (Registration Request) (7) AA-- Node-Answer (Registration Reply) (5) Home-- MP-Answer (Registration Reply) (4) Home-- MP-Request (Registration Request) (1) Registration Request (MN-AAA) IPv4 (8) Registraion Reply IPv4 Protocol Protocol de mobilité IPv4 Figure 11 Messages échangés en cas de succès lors de l accès d un mobile à un réseau 4.4.3 IPv4 et la réauthentification De par la nature de IPv4, une réauthentification du mobile ne peut être décidée qu à l initiative du mobile. Le message Re-Auth défini par (cf. 2.1) est donc inexploitable ici. Ainsi, lorsqu un certain laps de temps s est écoulé depuis la dernière authentification, cette durée étant précisée dans l AVP Authorization-Lifetime (cf. 2.2 et 3.3), le mobile doit émettre une nouvelle requête d enregistrement (Registration Request) à destination de son agent ; cette requête suivra le même cheminement que celui décrit à la figure 11 et la réauthentification sera effectuée de la même manière. 4.6 Traitement du handover Le traitement du handover est décrit très succinctement dans [15] et mériterait d être approfondi. En effet, il est primordial qu un mobile puisse continuer à communiquer même si au cours d un déplacement, il passe sous le contrôle d un autre agent, voire d un autre serveur. Il faut en effet éviter que chaque déplacement du mobile nécessite sa réauthentification intégrale avec tous les échanges associés au roaming (cf. 4.4) car cela perturberait ses communications au risque de provoquer des déconnexions. (0) 4.5 Nouveaux messages et AVP liés à l extension de mobilité IPv4 Quatre nouveaux messages sont définis et sont présentés dans le tableau 4. Les deux premiers sont utilisés pour la communication entre agent et serveurs ; les deux suivants servent à la communication entre le serveur et l agent. Tableau 4 Les quatre nouveaux messages définis pour IPv4 [15] Nom des messages Command Code AA--Node-Request 260 AA--Node-Answer 260 Home--MIP-Request 262 Home--MIP-Answer 262 Parmi les nombreux AVP définis dans [15], certains sont présentés dans le tableau 5. Leur utilisation est décrite dans le paragraphe 4.4. (0) Tableau 5 Quelques AVP définis dans [15] Nom des AVP AVP Code MIP-Filter-Rule 342 MIP-Home--Address 334 MIP-MN-AAA-Auth 322 MIP--Node-Address 333 MIP-Reg-Request 320 MIP-Reg-Reply 321 MIP-FA-to-HA-Key 328 MIP-FA-to-MN-Key 326 MIP-HA-to-FA-Key 329 MIP-HA-to-MN-Key 332 MIP-MN-to-FA-Key 325 MIP-MN-to-HA-Key 331 MIP-Feature-Vector 337 MIP-Candidate-Home--Host 336 MIP-Key-Lifetime 367 TE 7 555 10 Techniques de l Ingénieur, traité Réseaux et télécommunications

Dossier délivré pour GESTION DU ROAMING PAR AAA POUR LES SERVICES PPP ET MOBILE IP 5. dans les réseaux cellulaires de troisième génération Domaine d'administration (FAI, opérateur ) FAI de souscription de l'entreprise Réseau privé d'une entreprise Pour gérer les aspects AAA dans les réseaux cellulaires de troisième génération de type UMTS (Universal Telecommunications System) [TE 7 368] ou CDMA (Code Division Multiple Access) [TE 7 366], il apparaît intéressant d intégrer une infrastructure avec les extensions adéquates, et ce pour homogénéiser la gestion des fonctions AAA dans les réseaux. La solution est en effet introduite dans les technologies de réseaux existantes en remplacement de RADIUS et sera vraisemblablement implémentée dans toute technologie future (cf. 6). Il y a donc tout intérêt à l envisager dans les réseaux de troisième génération. C est d ailleurs en cours d étude pour les réseaux CDMA par le projet 3GPP2 [18]. C est principalement pour la quatrième génération de réseaux cellulaires que prendra toute son importance. En effet, cette quatrième génération devrait offrir des débits d au moins 100 Mbit/s et permettre aux utilisateurs de poursuivre leurs communications tout en se déplaçant de réseau en réseau, et ce quelle que soit la technologie de ces réseaux d accès. Par exemple, il sera possible, pour un utilisateur, de commencer à télécharger un fichier volumineux sur son ordinateur portable depuis son lieu de travail par le biais d un réseau Wi-Fi [TE 7 377] ; cet utilisateur partant en clientèle à ce moment-là pourra poursuivre ce téléchargement en basculant sur le réseau UMTS public. Dans ces conditions, on se rend bien compte qu il est primordial d avoir à disposition un moyen AAA commun aux différentes technologies de réseau pour gérer les utilisateurs. Le seul suffisamment mûr actuellement et offrant toutes les fonctionnalités souhaitées s appelle. 6. D autres utilisations possibles Dans quelques années, lorsque sera mûr, il sera possible d intégrer dans les produits de type Wi-Fi [TE 7 377], VPN [H 5 620], routeurs, etc. Le but sera alors de remplacer peu à peu les protocoles supportant l authentification comme le protocole RADIUS par. Pour le Wi-Fi, par exemple, l accès au réseau est protégé par un mot de passe qui est fourni par la station radio au point d accès ; dans les prochaines années, le point d accès au réseau pourra vérifier la validité de ce mot de passe en faisant appel à l infrastructure. Si est intégré dans les équipements VPN, il sera tout à fait possible d envisager des architectures comme celle de la figure 12 où l équipement VPN de l entreprise vient en aide au FAI pour authentifier les utilisateurs. Le scénario suivant pourrait alors se produire. Un employé d une entreprise souhaite, au cours d une mission, se connecter à l Intranet de son entreprise. Il se connecte donc à un domaine d administration qui lui demande de s authentifier. Le serveur prend en charge les procédures AAA. Pour cela, il contacte le serveur du FAI de souscription. On peut imaginer que ce dernier ne disposant pas des informations lui permettant de mener à bien l authentification relaye la demande au serveur de l entreprise cliente situé dans son équipement VPN. Cela suppose bien évidemment que le serveur soit jugé digne de confiance par le FAI, ce qui se produit en particulier si l entreprise sous-traite la gestion de son équipement VPN auprès du FAI. Figure 12 Architecture futuriste basée sur dans le cas d un accès distant Protocole PANA Figure 13 Architecture de PANA 7. Perspectives de standardisation Le succès de est fortement lié au protocole PANA qui facilitera l accès à l infrastructure, et dans un avenir plus lointain à la définition d une extension IPv6. 7.1 Protocole PANA AAP : machine IPv4 en déplacement Protocole VPN/ Infrastructure d'authentification PANA (AAP) : agent du domaine réalisant l'interface entre le mobile et l'infrastructure pour rendre les fonctions AAA, et ce quel que soit le réseau d'accès du mobile (Wi-Fi, GSM, GPRS, UMTS) Le protocole PANA (Protocol for carrying Authentication for Network Access) [19] qui est en cours de spécification à l IETF vise à définir un protocole général permettant aux utilisateurs mobiles d échanger des informations AAA avec le réseau d accès, et ce, quelle que soit la technologie d accès. Les utilisateurs mobiles sont tenus de s authentifier auprès d un agent de PANA appelé AAP pour d Authentification PANA (figure 13). L agent AAP peut réaliser l authentification lui-même ou bien faire appel à une infrastructure de type, auquel cas il sert d interface entre le mobile et cette infrastructure. Dans le cas d un accès distant par le réseau commuté, le NAS tient le rôle de l AAP. Dans un contexte de mobilité IPv4, c est l agent qui est fusionné à l AAP. PANA permet en fait d homogénéiser les architectures AAA en définissant l AAP et de rendre l infrastructure accessible quels que soient le terminal mobile utilisé et le réseau d accès du mobile. Lorsque le protocole PANA sera disponible, son exploitation nécessitera probablement des extensions dans les technologies d accès actuelles, et l obligation pour les futurs réseaux d accès de supporter ce protocole. Techniques de l Ingénieur, traité Réseaux et télécommunications TE 7 555 11

GESTION DU ROAMING PAR AAA POUR LES SERVICES PPP ET MOBILE IP Dossier délivré pour 7.2 Extension IPv6 de Le protocole de mobilité IPv6 étant pressenti pour les réseaux cellulaires d après troisième génération, la communauté scientifique de l IETF a initié des travaux sur la définition d une extension IPv6 de. Cette extension n en est en fait qu à ses balbutiements avec la publication de quelques drafts dont un sur les besoins liés à l extension IPv6 [20]. La définition de cette extension s avère difficile actuellement car le protocole de mobilité IPv6 est instable. De plus, l idée première de calquer l extension IPv6 sur l extension IPv4 s avère mauvaise car les protocoles de mobilité IPv4 et IPv6 sont très différents. Par exemple, le protocole de mobilité IPv6 ne faisant pas intervenir d agents relais, tout le problème repose sur la manière de contraindre le mobile à contacter l infrastructure pour s authentifier et d interdire l accès du mobile au domaine tant que son authentification n a pas abouti. Les solutions envisagées jusqu à présent font intervenir l équivalent d un agent qui va bloquer le trafic issu du mobile tant que le mobile ne s est pas authentifié avec succès. 8. Conclusions sur les perspectives d exploitation de Actuellement, RADIUS est le protocole systématiquement employé dès lors qu un équipement de réseau tel qu un NAS, un équipement VPN, un équipement Wi-Fi ou un routeur a besoin d authentifier et d autoriser un utilisateur, voire de collecter des informations liées à sa connexion. Cependant, le protocole offre de nombreux avantages par rapport à RADIUS : il offre un service AAA interdomaine ; il permet d autoriser un utilisateur à se connecter sans pour autant nécessiter son authentification ; il est possible de réauthentifier et/ou réautoriser un utilisateur en cours de connexion. Pour toutes ces raisons, le protocole est pressenti comme le protocole AAA de demain. Il est quasiment certain que sera exploité dans le cadre d une connexion à distance via le réseau commuté en remplacement de RADIUS. En effet, grâce à, les FAI n auront plus besoin de placer des points d accès à leur réseau un peu partout dans le monde. leur permettra de bénéficier du point d accès d autres FAI, et d augmenter ainsi leur couverture géographique à moindre coût. Un parallèle évident peut être établi avec les opérateurs de télécommunication mobile qui passent des accords avec des opérateurs étrangers pour bénéficier de leurs infrastructures déployées et ainsi assurer la continuité du service auprès de leurs clients lors de leurs séjours à l étranger. Toute la difficulté des FAI sera de s entendre sur les modalités de leurs accords. De la même façon que pour les opérateurs de télécommunications mobiles, cette étape de négociation risque d être longue. L avenir de l extension IP de apparaît plus incertain car il n existe pas encore de marché pour la mobilité IP. Il faudrait pour cela que certaines applications nécessitent l usage de ce protocole, ou mieux que les réseaux cellulaires de troisième génération CDMA soient déployés. Bibliographie [1] CALHOUN (P.R.), LOUGHNEY (J.), GUTTMAN (E.), ZORN (G.) et ARKKO (J.). base protocol - draft-ietf-aaa-diameter-17, déc. 2002. [2] ABOBA (B.), ARKKO (J.) et HARRINGTON (D.). Introduction to Accounting Management - rfc 2975, oct. 2000. [3] CALHOUN (P.R.), FARRELL (S.) et BULLEY (W.). CMS Security Application - draft-ietf-aaa-diameter-cms-sec-04, mars 2002. [4] BLOUNT (A.). Accounting Attributes and Record Formats - rfc 2924, sept. 2000. [5] STEWART (R.) et al. Stream Control Transmission Protocol - rfc 2960, oct. 2000. [6] ABOBA (B.) et WOOD (J.). Authentication, Authorization and Accounting (AAA) Transport Profile - draft-ietf-aaa-transport-12, janv. 2003. [7] SIMPSON (W.). The Point-to-Point Protocol (PPP) - rfc 1661, juil. 1994. [8] SIMPSON (W.). PPP Challenge Handshake Authentication Protocol (CHAP) - rfc 1994, août 1996. [9] ROUSSEAU (L.). Classes d authentification - le magazine de la sécurité informatique MISC, p. 62-66, juil./août 2002. [10] BLUNK (L.) et VOLLBRECHT (J.). PPP Extensible Authentication Protocol (EAP) - rfc 2284, mars 1998. [11] RIGNEY (C.), RUBENS (A.), SIMPSON (W.) et WILLENS (S.). Remote Authentication Dial In User Service (RADIUS) - rfc 2138, avr. 1997. [12] CALHOUN (P.R.), ZORN (G.), SPENCE (D.) et MITTON (D.). Network Access Server Application - draft-ietf-aaa-diameternasreq-11, févr. 2003. [13] ABOBA (B.) et BEADLES (M.). The Network Access Identifier - rfc 2486, janv. 1999. [14] HILLER (T.) et ZORN (G.). Extensible Authentication Protocol (EAP) Application - draft-ietf-aaa-eap-01, mars 2003. [15] CALHOUN (P.R.), JOHANSSON (T.) et PER- KINS (C.E.). IPv4 Application - draft-ietf-aaa-diameter-mobileip-13, oct. 2002. [16] GLASS (S.), HILLER (T.), JACOBS (S.) et PER- KINS (C.E.). IP Authentication, Authorization, and Accounting Requirements - rfc 2977, oct. 2000. [17] PERKINS (C.E.). IP Mobility Support for IPv4 - rfc 3220, janv. 2002. [18] PATEL (G.) et DENNETT (S.). The 3GPP and 3GPP2 Movements Toward an All_IP Network. IEEE Personal Communications, vol. 7, n o 4, p. 62-64, août 2000. [19] PENNO (R.), YEGIN (A.E.), OHBA (Y.), TSIRT- SIS (G.) et WANG (C.). Protocol for carrying Authentication for Network Access (PANA) Requirements and Terminology - draft-ietfpana-requirements-04, avr. 2003. [20] FACCIN (M.), LE (F.), PATIL (B.), PERKINS (C.E.), DUPONT (F.), LAURENT-MAKNAVI- CIUS (M.) et BOURNELLE (J.). IPv6 Authentication, Authorization, and Accounting Requirements - draft-le-aaa-mipv6- requirements-02, avr. 2003. Dans les Techniques de l Ingénieur CELLMER (J.). Réseaux cellulaires - Système CDMA - [TE 7 366], traité Télécoms, févr. 1999. CELLMER (J.). Réseaux cellulaires - Système UMTS - [TE 7 368], traité Télécoms, mai 2002. LAURENT-MAKNAVICIUS (M.). Protocole IPsec - [TE 7 545], traité Informatique, 2003. NOËL (T.). IP - [TE 7 515], traité Télécoms, févr. 2002. ACHEMLAL (M.) et DUDET (M.). Les technologies VPN. [H 5 620], traité Informatique, oct. 2003. LANDIN (G.). Authentification forte. [H 5 520], traité Informatique, oct. 2003. FOUQUE (P.A.). Cryptographie moderne et applications. [H 5 210], traité Informatique, oct. 2003. TESSEREAU (C.). Le protocole SSL (TLS et HTTPS). [H 5 230], traité Informatique, oct. 2003. MUHLETHALER (P.). Sécurité des réseaux sans fil (Bluetooth, Wi-Fi). [TE 7 377], traité Informatique, oct. 2003. TE 7 555 12 Techniques de l Ingénieur, traité Réseaux et télécommunications