Brevet FR2869190A1 — publié le 20051021

Procédé permettant à l'usager d'un terminal téléphonique sans fil d'établir une connexion d'urgence dans un réseau local; terminal et serveur pour la mise en oeuvre de ce procédé L'invention concerne un procédé permettant à l'usager d'un terminal téléphonique sans fil, destiné à être relié à un réseau local sans fil par exemple de type IEEE 802.11, d'établir une connexion d'urgence dans un réseau local, pour téléphoner à un centre de secours, même lorsque cet usager n'a pas de droit d'accès au réseau local sans fil qui dessert le lieu où il est à l'instant où il a besoin de secours. Dans les entreprises, il est de plus en plus courant d'utiliser un téléphone portable sans fil se connectant, par une liaison radio de type IEEE 802.11, à un réseau local informatique et téléphonique appartenant à une entreprise. Certains assistants numériques personnels et certains ordinateurs personnels offrent aussi cette fonction téléphonique. L'accès à un réseau local d'entreprise est généralement restreint à certains utilisateurs qui sont des employés de cette entreprise. Quand l'utilisateur d'un tel terminal est dans les locaux de l'entreprise qui l'emploie, il a un droit d'accès au réseau local, qui lui permet de téléphoner en toutes circonstances. Par contre, ce même utilisateur ne peut pas téléphoner quand il est dans les locaux d'une autre entreprise, parce qu'il ne dispose pas d'un droit d'accès dans le réseau local de cette autre entreprise. En particulier, il ne peux pas téléphoner à un centre de secours avec son terminal habituel, sauf si celui-ci est bimode, c'est à dire permettant aussi d'accéder à un réseau public de radiotéléphonie, tel qu'un réseau GSM. Dans les réseaux radio-téléphoniques publiques, notamment les réseaux de type GSM, un procédé connu permet à l'usager d'un terminal radiotéléphonique d'établir une connexion d'urgence dans ce réseau, pour téléphoner à un centre de secours, même lorsque cet usager n'a pas de droit d'accès au réseau qui couvre l'endroit où il est; et même s'il n'y a aucune carte SIM (Module d'identification de l'utilisateur) dans son terminal. Ce procédé connu consiste à autoriser un usager à accéder à un centre de commutation du service mobile, via une station de base et un contrôleur de stations de base, avant même que le terminal ait dû satisfaire à la procédure d'authentification de cet usager. Le centre de commutation du service mobile reçoit donc le numéro demandé et peut constater qu'il s'agit d'un numéro d'urgence. Dans ce cas, il ne déclenche pas la procédure d'authentification mais il établit la connexion demandée. Ce procédé n'est pas transposable dans un réseau de type IEEE 802.11 parce que, dans ce type de réseau, tous les procédés actuels d'établissement d'une connexion consistent à interdire a priori aux points d'accès radio d'établir une connexion entre un terminal et le réseau, avant que la procédure d'authentification soit satisfaite, sauf une connexion temporaire avec un serveur d'authentification, pour pouvoir réaliser cette procédure d'authentification. Le but de l'invention est de proposer un procédé permettant à l'usager d'un terminal téléphonique sans fil d'établir une connexion d'urgence dans un réseau local sans fil, pour téléphoner à un centre de secours, même lorsque cet usager n'a pas de droit d'accès à ce réseau local et que le procédé d'établissement d'une connexion dans ce réseau interdit a priori aux points d'accès radio d'établir une connexion entre un terminal et le réseau, avant que la procédure d'authentification soit satisfaite. L'objet de l'invention est un procédé permettant à l'usager d'un terminal téléphonique sans fil d'établir une connexion d'urgence dans un réseau local, comportant un serveur d'authentification, même lorsque cet usager n'a pas de droit d'accès à ce réseau local; caractérisé en ce qu'il consiste, quand l'usager a composé un numéro de téléphone d'urgence, à : reconnaître ce numéro comme numéro d'urgence et envoyer alors, du terminal à un point d'accès radio du réseau, un message de démarrage; - envoyer du point d'accès au terminal en réponse du message de démarrage un message demandant au terminal son identité ; - envoyer alors du terminal au point d'accès du réseau un message contenant l'identité du terminal et une indication signifiant que c'est un appel 30 d'urgence; - transmettre du point d'accès au serveur d'authentification un message contenant ladite information d'identité et une indication signifiant que c'est un appel d'urgence; - reconnaître, dans le serveur d'authentification, que ce message contient une indication signifiant que c'est un appel d'urgence, et envoyer alors un message d'acceptation à ce terminal, via le point d'accès; - reconnaître ce message d'acceptation lors de son transit via le point d'accès, et valider alors un port du point d'accès permettant à ce terminal d'établir une connexion d'urgence à travers le réseau local. L'invention a aussi pour objet un terminal téléphonique sans fil permettant à son usager d'établir une connexion d'urgence dans un réseau local sans fil, caractérisé en ce qu'il comporte de moyens pour: reconnaître un numéro comme numéro d'urgence quand l'usager a composé un numéro de téléphone d'urgence, et envoyer alors, du terminal à un point d'accès radio du réseau, un message de démarrage; - recevoir du point d'accès du réseau un message demandant au terminal son identité ; envoyer alors, du terminal au point d'accès, un message contenant l'identité du terminal, et une indication signifiant que c'est un appel d'urgence, ce message étant destiné à un serveur d'authentification; recevoir un message d'acceptation envoyé par le serveur d'authentification via ce point d'accès, et destiné à valider classiquement un port d'un point d'accès afin de permettre au terminal d'établir une connexion d'urgence à travers le réseau local; - et envoyer alors à ce point d'accès un message de demande d'établissement d'une connexion d'urgence à travers le réseau local. L'invention a aussi pour objet un serveur d'authentification permettant à l'usager d'un terminal téléphonique sans fil d'établir une connexion d'urgence dans un réseau local; caractérisé en ce qu'il comporte des moyens pour: - recevoir, via un point d'accès radio, un message provenant d'un terminal et contenant l'identité de ce terminal et une indication signifiant que c'est un appel d'urgence; - reconnaître dans ce message l'indication signifiant que c'est un appel d'urgence, et envoyer alors au terminal, via ce point d'accès, un message d'acceptation, destiné à valider classiquement un port de ce point d'accès afin de permettre au terminal d'établir une connexion d'urgence à travers le réseau local. L'invention sera mieux comprise et d'autres caractéristiques apparaîtront à l'aide de la description ci-dessous et des figures l'accompagnant: - La figure 1 représente le schéma d'un exemple de réseau local de type IEEE 802.1 1, dans lequel on peut mettre en oeuvre le procédé selon l'invention; - La figure 2 représente un chronogramme illustrant le procédé connu selon les normes IEEE 802.11 et IEEE 802.1x pour authentifier un terminal puis établir une connexion; - La figure 3 représente un chronogramme illustrant le procédé selon l'invention pour authentifier un terminal puis établir une connexion d'urgence sans authentifier ce terminal. Le réseau local 1PN de type IEEE 802.11 représenté sur la figure 1 comporte: un commutateur Ethernet ESW; - un serveur d'authentification AS, du type RADIUS (Remote Authentication Dial ln Service) par exemple, relié à un port du commutateur Ethernet ESW; - et des points d'accès radio API, AP2, AP3, reliés respectivement à des ports du commutateur Ethernet ESW; Le commutateur Ethernet ESW est relié à un commutateur téléphonique privé, IPBX, par le biais d'une passerelle, GW. Il permet d'établir des communications téléphoniques dans le réseau local 1PN. Ce commutateur téléphonique IPBX est relié aussi à un réseau public de téléphonie, PSTN. Des terminaux téléphoniques sans fil Tl, T2, T3, ..., et des ordinateurs portables PC1, PC2, ... sont reliés chacun à un des points d'accès radio API, AP2, AP3, par des liaisons radio IEEE 802.11g par exemple. L'authentification est faite en mettant en oeuvre par exemple le protocole appelé EAP (Extensible Authentication Protocol) décrit dans le document IEEE Std 802.1x - 2001, pour faire communiquer une entité de protocole (Supplicant PAE) qui demande une authentification, avec un serveur d'authentification (Authentication Server), via une entité de protocole (Authenticator PAE) qui réalise l'authentification. Ce protocole EAP peut supporter divers procédés d'authentification. On considérera ici à titre d'exemple une authentification par mot de passe à usage unique, mais le procédé selon l'invention peut être appliqué quel que soit le procédé d'authentification utilisé dans le cadre de la norme IEEE 802.11. A titre d'exemple, on considérera l'authentification du terminal téléphonique Tl. Chaque terminal téléphonique Tl, T2, T3, ..., et chaque ordinateur personnel PC1, PC2, ... du réseau comporte des moyens logiciels permettant à un port d'un point d'accès API, AP2, AP3, ... d'exécuter les procédures d'authentification de ce terminal. Ces moyens logiciels exécutent une entité de protocole référencée SPAE (Supplicant Port Acess Entity, selon la terminologie de la norme IEEE 802.1x). Chaque point d'accès API, AP2, AP3, ... comporte des moyens logiciels pour exécuter une entité de protocole associée à un port, cette entité étant destinée à retransmettre une demande d'authentification vers le serveur d'authentification AS. Cette entité est référencée APAE (Authenticator Port Acess Entity selon la terminologie de la norme IEEE 802.1x). La norme IEEE 802.1x définit un format d'encapsulation des messages du protocole EAP, pour les transmettre sur un réseau local. Cette encapsulation, appelée EAPOL, est utilisée par exemple pour toutes les communications entre le terminal Tl et le point d'accès API. Ce dernier reformate un message provenant du terminal Tl avant de le retransmettre au serveur d'authentification AS, conformément au protocole RADIUS. Le point d'accès API valide ou inhibe le port susceptible de relier le terminal Tl au réseau local, mais il n'interfère pas avec les échanges de messages entre le terminal Ti et le serveur d'authentification AS, ce qui permet d'utiliser un serveur d'authentification AS distant du point d'accès API. Le point d'accès API est initialisé de façon que le ce port est inhibé. Selon la norme IEEE 802.1x, le point d'accès API valide ce port lorsqu'il constate, en surveillant les échanges de messages entre le terminal Ti et le serveur d'authentification AS, que le terminal Tl a été authentifié par le serveur AS. La figure 2 représente un chronogramme illustrant le procédé connu selon les normes IEEE 802.11 et IEEE 802.Ix pour authentifier un terminal puis établir une connexion. II est mis en oeuvre dans le réseau représenté sur la figure 1 en utilisant des terminaux T1, T2, T3, ... , des points d'accès API, AP2, AP3,... et un serveur d'authentification AS classiques. La figure 2 représente les échanges de messages, conformément à la norme IEEE 802.1x, dans le cas où le terminal Ti est authentifié avec succès. Le procédé d'authentification décrit est un exemple seulement, la norme IEEE 802.1x supportant de nombreux autres procédés d'authentification. Cet échange de message a lieu lorsque le terminal est mis sous tension, ou lorsque le terminal entre sous la couverture radio d'un autre point d'accès. Dans le cas le plus courant, l'authentification est faite bien avant la demande d'établissement d'une communication. Etape 1: Lorsqu'il est mis sous tension, le terminal Ti envoie au point d'accès API un message de démarrage, appelé EAPOL-Start selon la terminologie de la norme IEEE 802.1x. Etape 2: le point d'accès API lui répond par un message demandant l'identité du terminal, ce message étant appelé EAP-Request / Identity. Etape 3: Le terminal T1 envoie au point d'accès API un message de réponse contenant l'identité du terminal, ce message étant appelé EAP-Response / Identity. Etape 4: Le point d'accès API reformate puis retransmet ce message de réponse au serveur d'authentification AS. Par contre, il ne laisse passer, pour le moment, aucun autre flux de données provenant du terminal Ti. Etape 5: Le serveur d'authentification AS envoie au point d'accès API un message de demande contenant un mot de passe à usage unique, appelé EAPRequest / OTP, OTP Challenge. Etape 6: Le point d'accès API reformate puis retransmet ce message de demande au terminal Ti. Etape 7: Le terminal TI envoie au point d'accès API un message de réponse, appelé EAP-Response / OTP, OTPpw. Etape 8: Le point d'accès API reformate puis retransmet ce message de réponse au serveur d'authentification AS. Etape 9: Le serveur d'authentification AS vérifie le message de réponse émis par le terminal T1. Si la vérification est positive, il envoie au point d'accès API un message d'acceptation, appelé EAP-Success. Ce message peut contenir des restrictions telles qu'un accès restreint à un réseau virtuel, sous-ensemble du réseau considéré, ou un ensemble de règles pare-feu. Étape 10: Le point d'accès prend connaissance de ce message d'acceptation, le reformate, puis le retransmet au terminal Tl, et il valide le port qui permettra au terminal Tl de communiquer avec l'ensemble du réseau local, et notamment le commutateur téléphonique IPBX. Ensuite, le terminal attend un événement, par exemple que l'utilisateur demande l'établissement d'une communication téléphonique. La figure 3 représente un chronogramme illustrant le procédé selon l'invention pour établir une connexion d'urgence sans authentifier un terminal. II est mis en oeuvre dans le réseau représenté sur la figure 1 en utilisant des terminauxTl, T2, T3, ... , et un serveur d'authentification AS dont les moyens logiciels respectifs ont été adaptés pour mettre en oeuvre le procédé selon l'invention. Les points d'accès API, AP2, AP3,... sont classiques, ils ne nécessitent pas de modification. Dans cet exemple, l'usager du terminal Ti n'a pas de droit d'accès dans le réseau IPN, mais il allume son terminal Tl, pour établir une connexion d'urgence, alors qu'il est dans la zone de couverture radio du réseau IPN. Etape 11 Lorsqu'il est mis sous tension, le terminal Tl envoie au point 20 d'accès API un message de démarrage, appelé EAPOL-Start. Etape 12 Le point d'accès API lui répond par un message demandant au terminal son identité, EAP-Request / ldentity. [tape 13 Le terminal Ti envoie au point d'accès API un message de réponse contenant l'identité du terminal, EAP-Response / ldentity. Etape 14 Le point d'accès AP1 reformate puis retransmet ce message de réponse au serveur d'authentification AS. Par contre, il ne laisse passer, pour le moment, aucun autre flux de données provenant du terminal Ti. Etape 15: Le serveur d'authentification AS envoie au point d'accès API un message de demande contenant un mot de passe à usage unique, EAP- Request / 30 OTP, OTP Challenge. Etape 16: Le point d'accès API reformate puis retransmet ce message de demande au terminal Tl. Etape 17: Le terminal Ti envoie au point d'accès API un message de réponse, appelé EAP-Response / OTP, OTPpw. Etape 18: Le point d'accès API reformate puis retransmet ce message de réponse au serveur d'authentification AS. Etape 19: Le serveur d'authentification AS vérifie le message de réponse émis par le terminal T1. La vérification est négative, il envoie donc au point d'accès API un message de refus. Etape 20: Le point d'accès prend connaissance de ce message de refus, et il ne valide donc pas le port qui permettrait au terminal Tl de communiquer avec l'ensemble du réseau local, et notamment le commutateur téléphonique IPBX. Ensuite, le terminal attend un événement, par exemple que l'utilisateur demande l'établissement d'une communication téléphonique d'urgence. Étape 21: L'usager compose un numéro téléphonique d'urgence (tel que 112 en Europe, ou 911 aux USA). Le terminal T1 envoie alors au point d'accès API le message de démarrage classique appelé EAPOL-Start. Ce message est déclenché par le fait que l'usager a composé, sur le clavier du terminal Tl, ou par une touche spécialisée, le numéro de téléphone d'urgence et que ce numéro a été reconnu comme numéro d'urgence par le terminal Tl. Étape 22: Le point d'accès API lui répond par le message classique de demande, contenant une information d'identité, EAP-Request / Identity. Etape 23: Le terminal Tl envoie au point d'accès API un message de réponse, d'un type nouveau, contenant ladite information d'identité et une indication signifiant que c'est un appel d'urgence. Par contre, le numéro de téléphone d'urgence (tel que 112 en Europe, ou 911 aux USA) peut ne pas être transmis. Etape 24: Le point d'accès API reformate puis retransmet ce message de réponse au serveur d'authentification AS. Etape 25: Le serveur d'authentification AS reconnaît dans le message l'indication signifiant que c'est un appel d'urgence. Le serveur d'authentification AS envoie alors au point d'accès API un message d'acceptation, d'un type nouveau, contenant une indication signifiant que c'est une authentification temporaire, valable seulement pour la durée d'un appel d'urgence c'est à dire jusqu'à une opération de libération, initialisée par le centre de secours qui a répondu à l'appel d'urgence. Le terminal Tl perdra alors tous ses droits d'accès au réseau. Etape 26: Le point d'accès API reformate puis retransmet ce message d'acceptation au terminal Tl, et il valide le port qui permettra au terminal Tl de communiquer avec l'ensemble du réseau local, jusqu'à ce qu'il reçoive un message de libération, envoyé par le centre de secours qui a répondu à l'appel d'urgence. Etape 27: Le terminal Ti envoie au point d'accès API un message de demande d'établissement d'une connexion téléphonique, mais ce message est d'un type particulier qui demande une connexion vers un centre de secours sans mentionner le numéro de téléphone d'urgence composé par l'usager (tel que 112 en Europe, ou 911 aux USA). Ce message sera acheminé par le réseau local jusqu'au commutateur IPBX, et c'est le commutateur IPBX qui composera un numéro de téléphone d'urgence. Ainsi il n'est pas possible d'utiliser ce procédé pour contourner l'authentification dans un but frauduleux. Selon une variante de réalisation, le serveur d 'authentification peut être intégré à un point d'accès radio, au lieu d'être distant. La portée de l'invention n'est pas limitée aux réseaux de type IEEE 802.1 1, elle peut être appliquée dans tout réseau où le procédé d'établissement d'une connexion dans ce réseau interdit a priori aux points d'accès radio d'établir une connexion entre un terminal et le réseau, avant que la procédure d'authentification soit satisfaite. REVENDICATIONS: 1) Procédé permettant à l'usager d'un terminal téléphonique sans fil (Ti) d'établir une connexion d'urgence dans un réseau local (IPN), comportant un serveur d'authentification (AS), même lorsque cet usager n'a pas de droit d'accès à ce réseau local; caractérisé en ce qu'il consiste, quand l'usager a composé un numéro de téléphone d'urgence, à : - reconnaître ce numéro comme numéro d'urgence et envoyer (21) alors, du terminal (T1) à un point d'accès radio (API) du réseau, un message de démarrage; - envoyer (22) du point d'accès (API) au terminal (Tl), en réponse au message de démarrage, un message demandant au terminal son identité ; - envoyer (23) alors du terminal (Tl) au point d'accès (API) du réseau un message contenant l'identité du terminal et une indication signifiant que c'est un appel d'urgence; - transmettre (24) du point d'accès (AM) au serveur d'authentification (AS) un message contenant ladite information d'identité et une indication signifiant que c'est un appel d'urgence; - reconnaître (25), dans le serveur d'authentification (AS), que ce message contient une indication signifiant que c'est un appel d'urgence, et envoyer alors un message d'acceptation à ce terminal (Tl), via le point d'accès (API) ; reconnaître (26) ce message d'acceptation lors de son transit via le point d'accès (API), et valider alors un port du point d'accès (API) permettant à ce terminal (Tl) d'établir une connexion d'urgence à travers le réseau local. 2) Terminal téléphonique sans fil (11) permettant à son usager d'établir une connexion d'urgence dans un réseau local sans fil (IPN), caractérisé en ce qu'il 30 comporte de moyens pour: - reconnaître un numéro comme numéro d'urgence quand l'usager a composé un numéro de téléphone d'urgence, et envoyer (21) alors, du terminal (Tl) à un point d'accès radio (API) du réseau, un message de démarrage; - recevoir (22) du point d'accès (API) du réseau un message de réponse demandant au terminal son identité ; - envoyer (23) alors, du terminal (Tl) au point d'accès (API), un message contenant l'identité du terminal, et une indication signifiant que c'est un appel d'urgence, ce message étant destiné à un serveur d'authentification (AS) ; - recevoir (26) un message d'acceptation envoyé par le serveur d'authentification (AS) via ce point d'accès (API), et destiné à valider classiquement un port d'un point d'accès (API) afin de permettre au terminal (Tl) d'établir une connexion d'urgence à travers le réseau local; - et envoyer alors (27) à ce point d'accès (API) un message de demande d'établissement d'une connexion d'urgence à travers le réseau local. 3) Serveur d'authentification (AS) permettant à l'usager d'un terminal téléphonique sans fil (Tl) d'établir une connexion d'urgence dans un réseau local; caractérisé en ce qu'il comporte des moyens pour: - recevoir (24), via un point d'accès radio (API), un message provenant d'un terminal (T1) et contenant l'identité de ce terminal et une indication signifiant que c'est un appel d'urgence; - reconnaître dans ce message l'indication signifiant que c'est un appel d'urgence, et envoyer (25) alors au terminal (Tl), via ce point d'accès (API), un message d'acceptation, destiné à valider classiquement un port de ce point d'accès (API) afin de permettre au terminal (Tl) d'établir une connexion d'urgence à travers le réseau local.