EP1900179A2 - Procede d'obtention de donnees de configuration pour un terminal par utilisation du protocole dhcp - Google Patents

Procede d'obtention de donnees de configuration pour un terminal par utilisation du protocole dhcp

Info

Publication number
EP1900179A2
EP1900179A2 EP06778966A EP06778966A EP1900179A2 EP 1900179 A2 EP1900179 A2 EP 1900179A2 EP 06778966 A EP06778966 A EP 06778966A EP 06778966 A EP06778966 A EP 06778966A EP 1900179 A2 EP1900179 A2 EP 1900179A2
Authority
EP
European Patent Office
Prior art keywords
dhcp
user
terminal
identifier
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP06778966A
Other languages
German (de)
English (en)
Inventor
Stéphane TUFFIN
François BOURDAIS
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP1900179A2 publication Critical patent/EP1900179A2/fr
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]

Definitions

  • the invention relates to a method for obtaining configuration data for a terminal by using the DHCP protocol. More specifically, the subject of the invention is a method for obtaining configuration data of a terminal as well as a method for processing by a server one or more DHCP requests issued by a DHCP client module of a terminal for obtaining configuration data from said terminal.
  • Dynamic Host Configuration Protocol DHCP
  • IP Internet Protocol
  • This protocol defines a set of requests for establishing a dialogue between, on the one hand, a client module implemented in the terminal and, on the other hand, a server module implemented in the server. These requests are sent either directly from the client module to the server module and vice versa, or through a DHCP relay.
  • the DHCP protocol can be used for different types of terminals: PC, router, IP phones, SetTopBox, videophones, video camera, etc., as such a terminal includes a DHCP client module able to communicate with a DHCP server module.
  • Such terminals are hereinafter referred to simply as IP terminals.
  • DHCP specifies that DHCP requests issued from a given terminal must contain the MAC address of the terminal. This MAC address uniquely identifies the network interface of the terminal, but it is insufficient to determine the nature of the terminal.
  • the DHCP protocol furthermore provides that the DHCP requests may contain optional data making it possible to manage the diversity of the terminals or the diversity of the needs of the users of these terminals.
  • These optional data are inserted into an option field of the query and include for example:
  • Some users may therefore need a static IP address - not a dynamic IP address - that allows them to access a particular service, for example a database that performs user identification. from its IP address and determines the access rights to the database data accordingly.
  • a known solution to this type of problem is to manually assign a static IP address to the terminal.
  • the disadvantage is that this solution involves the intervention of computer maintenance personnel for each case. In addition, it only works if the need is for a static IP address.
  • One of the aims of the invention is to provide a method for obtaining configuration data of a terminal by means of DHCP requests as well as a method for processing such requests, which do not have the drawbacks mentioned above for the previous solutions, which are compatible with the DHCP protocol and allow in particular a configuration data management of different terminals of a network that is fully automated and adaptable to the specific needs of certain users.
  • the subject of the invention is a method for obtaining configuration data of a terminal, the terminal comprising a DHCP client module able to communicate via a network with at least one DHCP server module according to the DHCP protocol, the method comprising the following steps:
  • DHCP client module generating by said DHCP client module one or more DHCP requests for obtaining configuration data from said terminal, transmission of said one or more DHCP requests via said network by said DHCP client module to said at least one DHCP server module,
  • the method further comprising a step of inserting into a predefined option field at least one of the requests DHCP, optional data comprising an associated identifier, directly or indirectly, to a single user of said terminal, the received configuration data being customized for said user.
  • the insertion in one of the requests of an identifier, associated with one and only one user of the terminal allows the generation of a response to this request which is personalized for a given user, identified, indirectly or indirectly by the identifier inserted. . In this way, the configuration data can be generated to meet the specific needs of a given user.
  • the method makes it possible to envisage a control over the generation of configuration data, and in particular to carry out an identification of the user as soon as he is connected to the network, or even to refuse the assignment of configuration data so as to prevent a user from accessing the network. Securing access to the network therefore occurs at the request of configuration, and is thus reinforced.
  • the method additionally provides a practical answer to situations of nomadism in which the same user can connect to a network using each time a different terminal, for example by using a terminal among a plurality of terminals accessible self-service.
  • the method is further compatible with DHCP and does not require modification of the basic principles of this protocol.
  • the method comprises a step of reading all or part of the optional data in a personal recording medium accessible from the terminal.
  • a recording medium is typically a smart card.
  • the personal recording medium is a medium whose access is secured by an identification code. This makes it possible to secure access to this identifier and its introduction in the request and reduces the chances of successful fraudulent use of personal recording media.
  • the personal recording medium is of the removable media type.
  • a user in a situation of mobility can thus bring his removable support to find a suitable and personalized configuration whatever the terminal he uses.
  • the personal recording medium is integrated in a mobile terminal and is accessible from said terminal by a local communication link established between said terminal and said mobile terminal.
  • This variant avoids the user of a mobile terminal, for example a mobile phone, to provide additional support for the storage of the identifier.
  • the identifier can be for example:
  • a user profile identifier associated with said user Any type of identifier can thus be used to implement the method according to the invention, it is not necessary to have an identifier of the user himself.
  • a registration identifier of a personal recording medium as identifier facilitates the implementation of the method, since such an identifier is pre-existing and databases are available. known mechanisms for processing such identifiers, and if necessary, to determine the identity of the user from such identifiers.
  • all or part of the optional data are inserted into the request in encrypted form. This increases the confidentiality of exchanges and limits the chances of successful fraudulent login attempts.
  • the invention also relates to a terminal comprising a DHCP client module, suitable for implementing the method according to the invention and comprising
  • the subject of the invention is also a method of processing by a server one or more DHCP requests issued by a DHCP client module of a terminal for obtaining configuration data of said terminal, the server comprising a DHCP server module capable of communicating with the DHCP client module via a network according to the DHCP protocol, at least one of said one or more received DHCP requests comprising, in a predefined option field, optional data including an associated identifier, directly or indirectly to a single user of said terminal, the method comprising the steps of
  • the configuration data being personalized for said user
  • the generated configuration data comprise an IP address whose static or dynamic type is a function of said identifier.
  • the method comprises a step of recording for each request comprising said predefined option field tracking data including date and / or time of receipt of said request.
  • said predefined option field tracking data including date and / or time of receipt of said request.
  • the method comprises steps of determining the identity of said user from said identifier, generating the requested configuration data according to the identity of said user in case of identification of the user, to refuse the generation of the requested configuration data in the case where said user is not identified.
  • the invention also relates to a server comprising a DHCP server module, suitable for implementing the processing method according to the invention, and comprising a module for generating said requested configuration data according to said identifier.
  • the server comprises a database comprising a list of identifiers, and for each identifier of the data corresponding to a description of the configuration requirements of the user associated with this identifier.
  • FIG. 1 is a simplified representation of the invention. architecture of a system for implementing the invention
  • FIG. 2 schematically illustrates different phases of the method according to the invention as well as data exchanges between the entities concerned by these different phases.
  • the invention is described in the context of its application to a situation in which a customer of a service provider wishes to access services made available through terminals accessing a network.
  • the terminals are, in this example, self-service terminals.
  • the customer begins by registering with the service provider for certain predefined services.
  • the service provider gives him a smart card.
  • This smart card contains information about the customer himself (ID
  • This terminal has a standard configuration, which is for example a configuration allowing only local use, without a network connection, of this terminal. To allow access to the services subscribed by a given user, it must be configured appropriately, and in particular have a DHCP address to access the services implemented via the network. Thanks to the invention, this terminal can be configured each time according to the identity of the user who connects to the network via this terminal, and this as soon as the connection to the network of the terminal is restored.
  • Figure 1 shows in a simplified manner the main elements cooperating in a system of such a terminal.
  • the terminal 100 is in communicating via a communication network 50 with a data processing server 200 accessing a database 300.
  • the terminal 100 is a microcomputer.
  • this terminal can be any type of terminal including a DHCP client module allowing access to the network 50.
  • the terminal 100 comprises a network card 1 15 compatible with the communication network 50. It also includes a 125 smart card reader. As a variant, the smart card reader 125 can be, not integrated in the terminal
  • the terminal 100 includes various software modules:
  • a DHCP client module 1 a driver 140 adapted to the smart card reader, a read module 150 accessing via the driver 140 to the data of the smart card, a data insertion module 170 used in combination with the DHCP client module 1 10,
  • the DHCP client module 1 10 of the terminal is adapted to interface with the data insertion module 170.
  • Either the DHCP client module 1 10 includes a software interface for communicating or interfacing with the insertion module 170, or it fully integrates the data insertion module 170.
  • the smart card acts as a personal recording medium.
  • Any other form of personal recording medium capable of storing data can also be envisaged: a USB electronic key connected via a USB port, a SIM card of a mobile phone accessible via a Bluetooth link between the terminal and the telephone, etc.
  • the means of access to the recording medium are each adapted to the recording medium used.
  • the access to the recording medium is secure so as to prevent fraudulent access to the data it contains or identity theft. This access security usually consists in allowing access to the data of the smart card only after provision of a confidential code.
  • the recording medium is a removable chip card type medium so that a given user can easily, even when is in frequent motion, connect from any terminal while finding a configuration appropriate to its needs.
  • the data processing server 200 comprises a network interface card 215 compatible with the communication network 50. It also includes a software module called DHCP 210 server module.
  • the DHCP client module and the DHCP server module are designed to interact with each other according to the DHCP protocol as defined by the IETF ("Internet Engineering Task Force") in the RFC 2131 standard.
  • This protocol defines in particular how a client terminal comprising a DHCP client module obtains its network configuration (its IP address, in general) from a DHCP server including a DHCP server module.
  • the requests sent by the client module to the server module are for example:
  • DHCP DISCOVER a "DHCP DISCOVER" request by which the client module tests the presence of one or more DHCP servers on the network and requests the establishment of a dialogue with one of these servers;
  • DHCP REQUEST a "DHCP REQUEST” request by which the client module requests configuration data from the server that has responded to its previous "DHCP DISCOVER” request; a "DHCP REQUEST RENEWAL” request by which the client module renews its previous “DHCP REQUEST” request.
  • DHCP requests issued by a DHCP client module may contain optional data. This data is identified in a DHCP request by an option code. For example, an option code 60 indicates the presence of data identifying the type of terminal.
  • an option field provided in the DHCP protocol is used to insert, in the DHCP request sent by the DHCP client module, an option code and data associated with this option code.
  • the inserted DHCP option complies with RFC 2489 standard. It is defined by: - an option code, for example code 180,
  • a parameter indicating the quantity of data associated with the option for example in the form of a number of characters.
  • an option will be named "option 180" or "user option”.
  • This predefined option code identifies the option field in which the identifier is inserted and is indicative that the configuration data requested by the client module is to be generated according to said identifier, and more specifically, that they are to be personalized. for the user associated with this identifier.
  • the data associated with the option code 180 includes an identifier associated, directly or indirectly, with one and only one user of the terminal 1, 10. Such an identifier makes it possible to determine without ambiguity the identity of the associated user. to this identifier.
  • Such an identifier can be, at choice: - an identifier of the user himself, for example his surname, first name;
  • an identifier of the user himself in coded form which is attributed to this user and makes it possible to identify him among other users within a given organization; it may be for example an employee identifier assigned to the user in the company for which he works or a customer identifier assigned to the user by a service provider organization of which this user is a customer;
  • a smart card registration identifier from which the identity of the user can be determined, the user associated with this identifier being in this case the owner of the smart card; an identifier of the type of telephone number from which the identity of the user can be determined, the user associated with this identifier being in this case the subscriber to the telephone line identified by this number,
  • an identifier of an abstract entity associated with a single user for example a user profile identifier associated with this user, etc.
  • a predefined option code identifying said option field is preferably used to indicate the presence of such an identifier and to indicate to the request processing module that the requested configuration data are to be customized for the user associated with the request. this identifier.
  • Other data can also be inserted into the query. These may or may not be extracted from the smart card. In particular, it may be useful to insert data identifying or describing a user profile. It can indeed be envisaged that a user needs to connect with different types of profiles to the terminal. For example, a user profile includes identification information of the services accessible from the terminal to which this user has subscribed. A User profile can also include information on the conditions of access to these services: time slot, number of access, etc.
  • the profile identifier may be the only data item integrated into the option field 180 because it can be used to identify the terminal user if this profile identifier is associated with a user. and only one.
  • the database preferably comprises a list of identifiers, and for each identifier of the corresponding data, either information relating to the services subscribed by the user associated with this identifier, or to a description of the configuration requirements of the the user associated with this identifier (type of address, access rights, etc.), or the configuration data themselves (in the case of a static address, it is necessary to memorize it). In this way, the server is thus able, without even knowing the identity of the user, to generate custom configuration data.
  • the data inserted in the request and associated with the option code 180 are preferably extracted from the smart card.
  • data from different sources for example non-confidential data, can also be inserted into the request.
  • Some or all of the data associated with option 180 may be encrypted.
  • the encryption of these data can be done, either before insertion of the data in the request, or before recording of the data on the smart card.
  • the risks of identity theft are very low, especially if access to the information medium is moreover secure.
  • FIG. 2 illustrates the different phases of the method according to the invention as well as the data exchanges carried out during these different phases between the terminal
  • this data notably comprises an identifier associated with a user of the terminal 100;
  • the reader 120 reads the data requested in the smart card 130 and sends them back to the terminal;
  • the server 200 processes the request "DHCP DISCOVER" by accessing S75 if necessary to the database 300; this processing is carried out taking into account all or part of the data read in the card and inserted in the request; the server 200 generates a response that preferably depends on the identifier inserted in the request;
  • the terminal 100 generates a request "DHCP REQUEST" and insert all or part of the previously read data in the card;
  • the server 200 processes the request "DHCP REQUEST" by accessing S135 if necessary to the database 300;
  • the server 200 sends a response to the request "DHCP REQUEST" in the form of a "DHCP ACK" request including an IP address intended for the configuration of the terminal 100;
  • the terminal 100 receives the response "DHCP ACK";
  • the terminal 100 proceeds to its IP configuration from the IP address returned by the server 200.
  • the constitution of a DHCP request by the terminal 100 itself comprises the following steps:
  • the DHCP client module 1 10 creates a DHCP request; the DHCP client module 1 10 transfers this request to the insertion module 170;
  • the insertion module 170 sends a request to the reading module 150 via the middleware 160 for the extraction of the data from the smart card; the reading module 150 obtains the requested data from the driver 140 of the card reader 120; the reading module 150 sends the requested data to the insertion module 170 via the middleware 160; the insertion module 170 inserts the data in the created DHCP request and the transfer to the DHCP client module 1; the DHCP client module sends the DHCP request to the DHCP server module 210 and waits for its response.
  • each generated DHCP request may include an option 180 and associated data.
  • the "DHCP DISCOVER” and “DHCP REQUEST” requests contain information on the identity of the user of the terminal. All requests issued by the DHCP client module ("DHCP REQUEST RENEWAL”, “DHCP INFORM” and “DHCP RELEASE”) may contain this information as needed.
  • DHCP REQUEST RENEWAL "DHCP INFORM”
  • DHCP RELEASE DHCP RELEASE
  • step S100 of generating a "DHCP REQUEST” request may require substeps S102 and S103 for access to the smart card and for reading data in the smart card.
  • the DHCP server is configured to use the information set in the chosen DHCP option in different ways:
  • the service provider can implement billing by user, for example depending on the number of connections or the duration of each connection, the tracking data being crossed with the information linking a customer to a smart card ; - to emit a response that is personalized according to the identity of the user or according to the services this user has subscribed to; for example by generating configuration data according to the identifier and / or the identity of the user.
  • the operation considered is a simple record of tracking data, it can optionally be executed after sending the response to the client request.
  • the processing by the server 200 of the DHCP request sent by the terminal 100 is performed according to the data of the optional data field. These data comprise an identifier, uniquely associated with the user of the terminal 100. This is in particular an identifier for a unique identification of the user of the terminal 100.
  • the DHCP server determines, prior to the processing of the DHCP request, the identity of the user of the terminal 100 and processes the request according to the identity of the user.
  • operations such as the recording of tracking data, the processing of the data associated with the request, the access control from the data associated with the request or the generation of the response to the request, can be performed according to the identity of the current user of the terminal 100.
  • the step of determining the identity of the user of the terminal can be avoided, if the server is designed to respond to the request solely on the basis of the identifier, especially if the server comprises a database registering the user configuration requirements in association with the identifier.
  • the DHCP server identifies from the identifier associated with the user the services subscribed by this user and returns a response (configuration data) that is adapted to the services subscribed.
  • the DHCP configuration returned by the server in response to a request "DHCP REQUEST" may be a function of the identifier, and therefore of the identity of this user. It is thus possible to ensure that the type, static or dynamic, of the returned address is also a function of the identity of this user. In the case of example where the user needs a static address, the server will always return a predefined static address tailored to that user's needs.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)
  • Communication Control (AREA)

Abstract

Le procédé comprend une étape consistant à insérer dans un champ d'option prédéfini d'une requête DHCP émise par module client DHCP pour l'obtention de 10 données de configuration, des données optionnelles comprenant un identifiant, directement ou indirectement, à un seul utilisateur dudit terminal, en vue de l'obtention de données de configuration personnalisées pour ledit utilisateur.

Description

Procédé d'obtention de données de configuration pour un terminal par utilisation du protocole DHCP
L'invention concerne un procédé d'obtention de données de configuration pour un terminal par utilisation du protocole DHCP. Plus précisément, l'invention a pour objet un procédé d'obtention de données de configuration d'un terminal ainsi qu'un procédé de traitement par un serveur d'une ou plusieurs requêtes DHCP émises par un module client DHCP d'un terminal pour l'obtention de données de configuration dudit terminal. Le protocole DHCP (Dynamic Host Configuration Protocol) permet à un terminal connecté à un réseau d'obtenir des données de configuration, notamment une adresse IP (Internet Protocol), auprès d'un serveur de traitement connecté à ce même réseau. Ce protocole définit un ensemble de requêtes permettant d'établir un dialogue entre, d'une part, un module client mis en ouvre dans le terminal et, d'autre part, un module serveur mis en œivre dans le serveur. Ces requêtes sont envoyées soit directement du module client au module serveur et vice versa, soit par le biais d'un relais DHCP.
Le protocole DHCP peut être utilisé pour différents types de terminaux: PC, routeur, téléphones IP, SetTopBox, visiophones, caméra vidéo, etc, dès lors qu'un tel terminal comprend un module client DHCP apte à dialoguer avec un module serveur DHCP. De tels terminaux sont dénommés ici de manière simplifiée terminaux IP.
Pour prendre en compte cette grande diversité de terminaux IP lors du traitement des requêtes DHCP, le protocole DHCP spécifie que les requêtes DHCP émises à partir d'un terminal donné doivent contenir l'adresse MAC du terminal. Cette adresse MAC permet d'identifier de manière univoque l'interface réseau du terminal, mais elle est insuffisante pour déterminer la nature du terminal.
Le protocole DHCP prévoit par ailleurs que les requêtes DHCP peuvent contenir des données optionnelles permettant de gérer la diversité des terminaux ou la diversité des besoins des utilisateurs de ces terminaux. Ces données optionnelles sont insérées dans un champ d'option de la requête et comprennent par exemple:
- des données qui identifient le type de terminal, ces données étant envoyées en utilisant l'option 60 du protocole DHCP ("Vendor Class Identifier");
- des données qui identifient un groupe d'utilisateurs ou un ensemble d'applications associé à ce groupe d'utilisateur, ces données étant envoyées en utilisant l'option 77 du protocole DHCP ("User Class"); - des données qui identifient la ligne réseau d'arrivée de la requête, lorsque les requêtes sont interceptées par un relais DHC interconnectant au moins deux réseaux, ces données étant envoyées en utilisant l'option 82 du protocole DHCP.
Ces différentes données permettent de traiter de manière appropriée la requête DHCP qui les contient. En effet, il est notamment possible de générer une réponse qui est fonction soit du type de terminal émetteur, soit du groupe d'utilisateur, soit encore du réseau d'arrivée de la requête. En particulier, l'adresse IP générée peut être fonction de ces données. L'affectation dynamique d'adresse IP aux terminaux d'un réseau peut ainsi être exécutée de manière automatique, à partir de telles données.
Toutefois, il existe des cas particuliers dans lesquels certains utilisateurs, appartenant à un groupe d'utilisateur donné, peuvent avoir des besoins spécifiques en terme de configuration réseau. Certains utilisateurs peuvent ainsi avoir besoin d'une adresse IP statique - et non pas d'une adresse IP dynamique - qui leur permette d'accéder à un service particulier, par exemple à une base de données qui procède à une identification de l'utilisateur à partir de son adresse IP et détermine en conséquence les droits d'accès aux données de la base.
Une solution connue à ce type de problème est d'attribuer manuellement une adresse IP statique au terminal. L'inconvénient est que cette solution suppose une intervention du personnel de maintenance informatique pour chaque cas de figure. En outre, elle ne fonctionne que dans le cas où le besoin est celui d'une adresse IP statique.
Un des buts de l'invention est de fournir un procédé d'obtention de données de configuration d'un terminal au moyen de requêtes DHCP ainsi qu'un procédé de traitement de telles requêtes, qui ne présentent pas les inconvénients évoqués plus haut pour les solutions antérieures, qui soient compatibles avec le protocole DHCP et permettent notamment une gestion des données de configurations des différents terminaux d'un réseau qui soit entièrement automatisable et adaptable aux besoins spécifiques de certains utilisateurs. Dans ce but l'invention a pour objet un procédé d'obtention de données de configuration d'un terminal, le terminal comprenant un module client DHCP apte à communiquer via un réseau avec au moins un module serveur DHCP conformément au protocole DHCP, le procédé comprenant les étapes suivantes:
- génération par ledit module client DHCP d'une ou plusieurs requêtes DHCP pour l'obtention de données de configuration dudit terminal, - transmission desdites une ou plusieurs requêtes DHCP via ledit réseau par ledit module client DHCP audit au moins un module serveur DHCP,
- réception des données de configuration reçues par ledit module client DHCP en réponse à au moins une desdites une ou plusieurs requêtes DHCP, le procédé comprenant en outre une étape consistant à insérer, dans un champ d'option prédéfini d'au moins une des requêtes DHCP, des données optionnelles comprenant un identifiant associé, directement ou indirectement, à un seul utilisateur dudit terminal, les données de configuration reçues étant personnalisées pour ledit utilisateur. L'insertion dans une des requêtes d'un identifiant, associé à un et un seul utilisateur du terminal, permet la génération d'une réponse à cette requête qui est personnalisée pour un utilisateur donné, identifié, indirectement ou indirectement par l'identifiant inséré. De la sorte, les données de configuration peuvent être générées de manière à répondre aux besoins spécifiques d'un utilisateur donné. De plus, le procédé permet d'envisager un contrôle sur la génération de données de configuration, et notamment, d'effectuer une identification de l'utilisateur dès sa connexion au réseau, voire de refuser l'attribution de données de configuration de manière à empêcher un utilisateur d'accéder au réseau. La sécurisation de l'accès au réseau intervient de ce fait dès la demande de configuration, et est ainsi renforcée.
Le procédé apporte de surcroît une réponse pratique aux situations de nomadisme dans lesquelles un même utilisateur peut se connecter à un réseau en utilisant chaque fois un terminal différent, par exemple en utilisant un terminal parmi une pluralité de terminaux accessibles en libre service. Enfin, le procédé est en outre compatible avec le protocole DHCP et ne nécessite pas de modification des principes de base de ce protocole.
Selon un mode de réalisation avantageux, le procédé comprend une étape consistant à lire tout ou partie des données optionnelles dans un support personnel d'enregistrement accessible à partir du terminal. Un tel support d'enregistrement est typiquement une carte à puce. Ce mode de réalisation permet de faciliter l'étape d'insertion de l'identifiant dans la requête DHCP, un simple dispositif de lecture de carte à puce étant nécessaire.
Selon une variante de ce mode de réalisation, le support personnel d'enregistrement est un support dont l'accès est sécurisé par un code d'identification. Ceci permet de sécuriser l'accès à cet identifiant et son introduction dans la requête et réduit les chances de succès d'une utilisation frauduleuse du support personnel d'enregistrement.
Selon une autre variante de ce mode de réalisation, le support personnel d'enregistrement est de type support amovible. Un utilisateur en situation de mobilité peut ainsi se munir de son support amovible pour retrouver une configuration adaptée et personnalisée quel que soit le terminal qu'il utilise.
Selon une autre variante de ce mode de réalisation, le support personnel d'enregistrement est intégré dans un terminal mobile et est accessible à partir dudit terminal par un lien local de communication établi entre ledit terminal et ledit terminal mobile. Cette variante évite à l'utilisateur d'un terminal mobile, par exemple d'un téléphone mobile, de se munir d'un support supplémentaire pour le stockage de l'identifiant.
L'identifiant peut être par exemple:
- un identifiant dudit utilisateur, - un identifiant d'immatriculation d'un support personnel d'enregistrement associé audit utilisateur,
- un identifiant d'un objet associé audit utilisateur,
- un identifiant d'un service associé audit utilisateur,
- un identifiant de profil utilisateur associé audit utilisateur. Tout type d'identifiant peut ainsi être utilisé pour la mise en œivre du procédé selon l'invention, il n'est pas nécessaire de disposer d'un identifiant de l'utilisateur lui- même. Par exemple, l'utilisation d'un identifiant d'immatriculation d'un support personnel d'enregistrement comme identifiant facilite la mise en oeuvre du procédé, puisque qu'un tel identifiant est préexistant et qu'on dispose de bases de données et de mécanismes connus permettant de traiter de tels identifiants, et permettant si besoin, de déterminer l'identité de l'utilisateur à partir de tels identifiants.
Selon un mode de réalisation avantageux, tout ou partie des données optionnelles sont insérées dans la requête sous forme chiffrée. Ceci permet de renforcer la confidentialité des échanges et limite les chances de succès de tentatives de connexion frauduleuses.
L'invention a également pour objet un terminal comprenant un module client DHCP, convenant à la mise en œivre du procédé de selon l'invention et comprenant
- un module pour provoquer l'insertion desdites données optionnelles dans ledit champ d'option prédéfini, - un module pour provoquer la lecture de tout ou partie desdites données optionnelles dans un support personnel d'enregistrement appartenant audit utilisateur et accessible à partir du terminal.
De manière complémentaire, l'invention a également pour objet un procédé de traitement par un serveur d'une ou plusieurs requêtes DHCP émises par un module client DHCP d'un terminal pour l'obtention de données de configuration dudit terminal, le serveur comprenant un module serveur DHCP apte à communiquer avec le module client DHCP via un réseau conformément au protocole DHCP, au moins une desdites une ou plusieurs requêtes DHCP reçues comprenant, dans un champ d'option prédéfini, des données optionnelles comprenant un identifiant associé, directement ou indirectement, à un seul utilisateur dudit terminal, le procédé comprenant les étapes consistant à
- générer les données de configuration demandées, les données de configuration étant personnalisées pour ledit utilisateur,
- transmettre audit module client DHCP les données de configuration en réponse à au moins une desdites une ou plusieurs requêtes DHCP.
Selon un mode de réalisation avantageux, les données de configuration générées comprennent une adresse IP, dont le type statique ou dynamique est fonction dudit identifiant. Le procédé permet ainsi la mise en place d'un processus automatique de gestion des adresses statiques à partir de la connaissance de chacun des identifiants associés aux utilisateurs ayant besoin d'une adresse statique.
Selon un mode de réalisation avantageux, le procédé comprend une étape consistant à enregistrer pour chaque requête comprenant ledit champ d'option prédéfini des données de suivi comprenant des informations de date et/ou heure de réception de ladite requête. Dans ce mode de réalisation, il est possible de suivre un utilisateur donné grâce à l'identifiant ou aux identifiants qui lui sont associés et d'envisager la mise en place de fonction de facturations ou de suivi des connexions.
Selon un mode de réalisation avantageux, le procédé comprend des étapes consistant à déterminer l'identité dudit utilisateur à partir dudit identifiant, à générer les données de configuration demandées en fonction de l'identité dudit utilisateur en cas d'identification de l'utilisateur, à refuser la génération des données de configuration demandées dans le cas où ledit utilisateur n'est pas identifié. Ce mode de réalisation permet de renforcer la sécurisation de l'accès au réseau dès l'étape de traitement des demandes de configuration.
L'invention a également pour objet un serveur comprenant un module serveur DHCP, convenant à la mise en œivre du procédé de traitement selon l'invention, et comprenant un module pour générer lesdites données de configuration demandées en fonction dudit identifiant.
Selon un mode de réalisation avantageux, le serveur comprend une base de données comprenant une liste d'identifiants, et pour chaque identifiant des données correspondant à une description des besoins en configuration de l'utilisateur associé à cet identifiant.
D'autres buts, caractéristiques et avantages de l'invention apparaîtront à travers la description qui va suivre, donnée uniquement à titre d'exemple non limitatif, et faite par référence aux dessins annexés dans lesquels - la figure 1 représente de manière simplifiée l'architecture d'un système pour la mise en œivre de l'invention,
- la figure 2 illustre de manière schématique différentes phases du procédé selon l'invention ainsi que les échanges de données entre les entités concernées par ces différentes phases. L'invention est décrite dans le cadre de son application à une situation dans laquelle un client d'un prestataire de service souhaite accéder à des services mis à disposition par le biais de terminaux accédant à un réseau. Les terminaux sont, dans cet exemple, des terminaux accessibles en libre service.
Le client commence par s'inscrire auprès du prestataire de service pour certains services prédéfinis. En échange, le prestataire de service lui remet une carte à puce. Cette carte à puce contient des informations sur le client lui-même (identifiant
Y), des informations de type service (le client a souscrit au service X, le client a souscrit à un abonnement de 12 mois) ou des informations mixtes (le client Y a souscrit au service X pour 12 mois). Le client achète ou obtient du prestataire de service un terminal pour accéder aux services souscrits. Ce terminal possède une configuration standard, qui est par exemple une configuration permettant uniquement un usage en local, sans connexion réseau, de ce terminal. Pour permettre l'accès aux services souscrits par un utilisateur donné, il doit être configuré de manière appropriée, et notamment disposer d'une adresse DHCP lui permettant d'accéder aux services mis en œivre via le réseau. Grâce à l'invention, ce terminal peut être configuré chaque fois en fonction de l'identité de l'utilisateur qui se connecte au réseau via ce terminal, et ce dès rétablissement de la connexion au réseau du terminal.
La figure 1 représente de manière simplifiée les principaux éléments coopérant dans un système d'un tel terminal. Dans le système représenté, le terminal 100 est en communication via un réseau 50 de communication avec un serveur 200 de traitement de données accédant à une base de données 300.
Le terminal 100 est dans cet exemple un micro-ordinateur. De manière générale, ce terminal peut être tout type de terminal comprenant un module client DHCP permettant l'accès au réseau 50.
Le terminal 100 comprend une carte réseau 1 15 compatible avec le réseau 50 de communication. Il comprend également un lecteur 125 de carte à puce. En variante, le lecteur 125 de carte à puce peut être, non pas intégré dans le terminal
100, mais raccordé à ce terminal 100 via un port de communication externe ou encore en liaison de communication avec le terminal 100.
Le terminal 100 comprend différents modules logiciels:
- un module 1 10 client DHCP, un pilote 140 adapté au lecteur de carte à puce, un module 150 de lecture accédant via le pilote 140 aux données de la carte à puce, un module 170 d'insertion de données utilisé en combinaison avec le module client DHCP 1 10,
- une interface 160 de communication de type middleware permettant la communication entre le module 150 de lecture et le module 170 d'insertion. Le module 1 10 client DHCP du terminal est adapté pour s'interfacer avec le module 170 d'insertion de données. Soit le module 1 10 client DHCP comprend une interface logicielle pour communiquer ou s'interfacer avec le module 170 d'insertion, soit il intègre complètement le module 170 d'insertion de données.
La carte à puce joue le rôle de support personnel d'enregistrement. Tout autre forme de support personnel d'enregistrement capable de stocker des données est également envisageable: une clé électronique USB connectée via un port USB, carte SIM d'un téléphone portable accessible via une liaison Bluetooth entre le terminal et le téléphone, etc. Les moyens d'accès au support d'enregistrement (dans l'exemple décrit, le pilote 140) sont chaque fois adaptés au support d'enregistrement utilisé. De préférence l'accès au support d'enregistrement est sécurisé de manière à éviter un accès frauduleux aux données qu'il contient ou une usurpation d'identité. Cette sécurisation d'accès consiste usuellement à n'autoriser l'accès aux données de la carte à puce qu'après fourniture d'un code confidentiel.
De préférence, le support d'enregistrement est un support amovible de type carte à puce de façon à ce qu'un utilisateur donné puisse facilement, même lorsqu'il est en déplacement fréquent, se connecter à partir de n'importe quel terminal tout en retrouvant une configuration appropriée à ses besoins.
De retour à la figure 1 , le serveur 200 de traitement de données comprend une carte d'interface réseau 215 compatible avec le réseau 50 de communication. Il comprend également un module logiciel dit module serveur DHCP 210.
Le module client DHCP et le module serveur DHCP sont conçus pour dialoguer entre eux selon le protocole DHCP tel que défini par l'IETF ("Internet Engineering Task Force") dans la norme RFC 2131. Ce protocole définit notamment comment un terminal client comprenant un module client DHCP obtient sa configuration réseau (son adresse IP, en général) auprès d'un serveur DHCP comprenant un module serveur DHCP.
Les requêtes envoyées par le module client au module serveur sont par exemple:
- une requête "DHCP DISCOVER" par laquelle le module client teste la présence d'un ou de plusieurs serveurs DHCP sur le réseau et demande l'établissement d'un dialogue avec un de ces serveurs;
- une requête "DHCP REQUEST" par laquelle le module client demande des données de configuration au serveur ayant répondu à sa précédente requête "DHCP DISCOVER"; - une requête "DHCP REQUEST RENEWAL" par laquelle le module client renouvelle sa précédente requête "DHCP REQUEST".
Les requêtes DHCP émises par un module client DHCP peuvent contenir des données optionnelles. Ces données sont identifiées dans une requête DHCP par un code d'option. Par exemple, un code d'option 60 indique la présence de données identifiant le type de terminal.
Selon l'invention, on utilise un champ d'option prévu dans le protocole DHCP pour insérer, dans la requête DHCP émise par le module client DHCP, un code d'option et des données associées à ce code d'option.
L'option DHCP insérée est conforme à la norme RFC 2489. Elle est définie par: - un code d'option, par exemple le code 180,
- un paramètre indiquant le format des données associées à l'option, par exemple "string",
- un paramètre indiquant la quantité de données associées à l'option, par exemple sous forme de nombre de caractères. Dans la suite de la description, une telle option sera nommée "option 180" ou "option utilisateur". Ce code d'option prédéfini identifie le champ d'option dans lequel est inséré l'identifiant et est indicatif que les données de configuration demandées par le module client sont à générer en fonction dudit identifiant, et plus précisément, qu'elles sont à personnaliser pour l'utilisateur associé à cet identifiant. Selon l'invention, les données associées au code d'option 180 comprennent un identifiant associé, directement ou indirectement, à un et un seul utilisateur du terminal 1 10. Un tel identifiant permet de déterminer sans ambiguïté l'identité de l'utilisateur associé à cet identifiant.
Un tel identifiant peut être, au choix: - un identifiant de l'utilisateur lui-même, par exemple son nom, prénom;
- un identifiant de l'utilisateur lui-même sous forme de codée, qui est attribué à cet utilisateur et permet de l'identifier parmi d'autres utilisateurs au sein d'une organisation donnée; il peut s'agir par exemple un identifiant de salarié attribué à l'utilisateur dans l'entreprise pour laquelle il travaille ou encore un identifiant de client attribué à l'utilisateur par un organisme prestataire de service dont cet utilisateur est client;
- un identifiant d'immatriculation de carte à puce, à partir duquel l'identité de l'utilisateur peut être déterminée, l'utilisateur associé à cet identifiant étant dans ce cas le propriétaire de la carte à puce; - un identifiant de type numéro de téléphone à partir duquel l'identité de l'utilisateur peut être déterminée, l'utilisateur associé à cet identifiant étant dans ce cas l'abonné à la ligne téléphonique identifiée par ce numéro,
- un identifiant d'un objet ou d'un service associé à un seul utilisateur,
- un identifiant d'une entité abstraite associée à un unique utilisateur, par exemple un identifiant de profil utilisateur associé à cet utilisateur, etc.
Un code d'option prédéfini identifiant ledit champ d'option est de préférence utilisé pour indiquer la présence d'un tel identifiant et préciser au module de traitement de la requête, que les données de configuration demandées sont à personnaliser pour l'utilisateur associé à cet identifiant. D'autres données peuvent également être insérées dans la requête. Celles-ci peuvent ou non être extraites de la carte à puce. Il peut notamment être utile d'insérer des données identifiant ou décrivant un profil utilisateur. On peut en effet envisager qu'un utilisateur ait besoin de se connecter avec différents types de profils au terminal. Un profil utilisateur comprend par exemple des informations d'identification des services accessibles à partir du terminal auxquels a souscrit cet utilisateur. Un profil utilisateur peut comprendre également des informations sur les conditions d'accès à ces services: plage horaire, nombre d'accès, etc.
En variante, seul un identifiant de profil est inséré dans la requête, le serveur
200 étant dans ce cas en mesure de restituer les informations relatives aux services associés à ce profil à partir de la base de données 300.
En outre, comme indiqué plus haut, l'identifiant de profil peut être la seule et unique donnée intégrée dans le champ d'option 180 car il peut être utilisé pour identifier l'utilisateur du terminal si cet identifiant de profil est associé à un utilisateur et un seul. Dans ce but, la base de données comprenant de préférence une liste d'identifiants, et pour chaque identifiant des données correspondant, soit des informations relatives aux services souscrits par l'utilisateur associé à cet identifiant, soit à une description des besoins en configuration de l'utilisateur associé à cet identifiant (type d'adresse, droits d'accès, etc), soit aux données de configuration elles-mêmes (dans le cas d'une adresse statique, il est nécessaire de mémoriser celle-ci). De cette manière, le serveur est ainsi en mesure, sans même connaître l'identité de l'utilisateur, de générer des données de configuration personnalisées. Les données insérées dans la requête et associées au code d'option 180 sont de préférence extraites de la carte à puce. En supplément, des données de provenance différente, par exemple des données non confidentielles, peuvent également être insérées dans la requête.
Tout ou partie des données associées à l'option 180 peut être chiffré. Le chiffrement de ces données peut s'effectuer, soit avant insertion des données dans la requête, soit avant enregistrement des données sur la carte à puce. Dans cette deuxième variante, les risques d'usurpation d'identité sont très réduits, surtout si l'accès au support d'information est de surcroît sécurisé.
La figure 2 illustre les différentes phases du procédé selon l'invention ainsi que les échanges de données effectués lors de ces différentes phases entre le terminal
100, le serveur 200, le lecteur 120 et la base de données 300. Après démarrage du terminal 100 et insertion de la carte à puce 130 dans le lecteur 120, les étapes S10 à S160 se déroulent comme suit:
- S10 : le terminal 100 génère une requête "DHCP DISCOVER" et demande l'insertion d'une option 180 comprenant des données présentes dans la carte à puce
130; ces données comprennent notamment un identifiant associé à un utilisateur du terminal 100; - S20 : le lecteur 120 reçoit une instruction de lecture de données;
- S30 : le lecteur 120 lit les données demandées dans la carte à puce 130 et les renvoie au terminal;
- S40 : le terminal 100 reçoit les données lues dans la carte à puce 130; - S50 : le terminal 100 insère les données reçues dans la requête "DHCP
DISCOVER", puis envoie cette requête au serveur 200;
- S60 : le serveur 200 reçoit la requête "DHCP DISCOVER";
- S70 : le serveur 200 traite la requête "DHCP DISCOVER" en accédant S75 si besoin à la base de données 300; ce traitement est effectué en prenant en compte tout ou partie des données lues dans la carte et insérées dans la requête; le serveur 200 génère une réponse qui, de préférence, est fonction de l'identifiant inséré dans la requête;
- S80 : le serveur 200 envoie une réponse à la requête "DHCP DISCOVER" sous forme d'une requête "DHCP OFFER"; - S90 : le terminal 100 reçoit la réponse "DHCP OFFER";
- S100 : le terminal 100 génère une requête "DHCP REQUEST" et y insert tout ou partie des données précédemment lues dans la carte;
- S1 10 : le terminal 100 envoie cette requête "DHCP REQUEST" au serveur 200; - S120 : le serveur 200 reçoit la requête "DHCP REQUEST ";
- S130 : le serveur 200 traite la requête "DHCP REQUEST " en accédant S135 si besoin à la base de données 300;
- S140 : le serveur 200 envoie une réponse à la requête "DHCP REQUEST " sous forme d'une requête "DHCP ACK" comprenant une adresse IP destinée à la configuration du terminal 100;
- S150 : le terminal 100 reçoit la réponse "DHCP ACK";
- S160 : le terminal 100 procède à sa configuration IP à partir de l'adresse IP renvoyée par le serveur 200.
La constitution d'une requête DHCP par le terminal 100 comprend elle-même les étapes suivantes:
- le module 1 10 client DHCP crée une requête DHCP; le module 1 10 client DHCP transfert cette requête au module 170 d'insertion;
- le module 170 d'insertion envoie une requête au module 150 de lecture via le middleware 160 pour l'extraction des données de la carte à puce; - le module 150 de lecture obtient les données demandées du pilote 140 du lecteur 120 de carte; le module 150 de lecture renvoie les données demandées au module 170 d'insertion via le middleware 160; - le module 170 d'insertion insère les données dans la requête DHCP créée et la transfert au module 1 10 client DHCP; le module 1 10 client DHCP envoi la requête DHCP au module 210 serveur DHCP et attend sa réponse.
Dans chaque requête DHCP générée peut comprendre une option 180 et des données associées. Dans l'exemple décrit, ce sont les requêtes "DHCP DISCOVER" et "DHCP REQUEST" qui contiennent une information sur l'identité de l'utilisateur du terminal. Toutes les requêtes émises par le module client DHCP ("DHCP REQUEST RENEWAL", "DHCP INFORM" et "DHCP RELEASE") peuvent selon le besoin contenir cette information. Selon les variantes de réalisation, il y aura ou non accès à la carte à puce à chaque génération de requête DHCP cliente pour y lire les données à insérer. Ainsi l'étape S100 de génération d'une requête "DHCP REQUEST" peut nécessiter des sous-étapes S102 et S103 d'accès à la carte à puce et de lecture de données dans la carte à puce. Le serveur DHCP est configuré pour se servir de l'information positionnée dans l'option DHCP choisie de différentes manières:
- pour effectuer des opérations de type contrôle d'accès en fonction de l'identité de l'utilisateur et ne répondre qu'aux terminaux envoyant une information associé à un utilisateur connu; dans ce cas, la sécurité du service DHCP est améliorée puisque l'on ne configure que les terminaux autorisés; dans cette situation des données d'authentification (mot de passe, certificat, etc) peuvent être insérées dans la requête DHCP avec les données permettant d'identifier l'utilisateur et permettre au serveur d'authentifier l'utilisateur courant du terminal émetteur de la requête;
- pour enregistrer des données de suivi (notamment les date et/ou heure de réception de la requête) relatives aux connexions demandées par un utilisateur donné, c'est-à-dire pour les requêtes comprenant le champ d'option 180; dans ce cas, le prestataire de service peut mettre en oeuvre une facturation par utilisateur, par exemple en fonction du nombre de connexions ou de la durée de chaque connexion, les données de suivi étant croisées avec les informations liant un client à une carte à puce; - pour émettre une réponse qui est personnalisée en fonction de l'identité de l'utilisateur ou en fonction des services auxquels cet utilisateur a souscrit; par exemple en générant des données de configuration en fonction de l'identifiant et/ou de l'identité de l'utilisateur. Ces différentes opérations sont effectuées de préférence lors du traitement de la requête DHCP cliente et avant l'élaboration de la réponse à cette requête. Lorsque l'opération considérée est un simple enregistrement de données de suivi, celle-ci peut optionnellement être exécutée postérieurement à l'envoi de la réponse à la requête cliente. En généralisant, le traitement par le serveur 200 de la requête DHCP émise par le terminal 100 est effectué en fonction des données du champ optionnel de données. Ces données comprennent un identifiant associé, de manière univoque, à l'utilisateur du terminal 100. Il s'agit en particulier d'un identifiant permettant une identification univoque de l'utilisateur du terminal 100. A partir des données associées à l'option DHCP, le serveur DHCP détermine, préalablement au traitement de la requête DHCP, l'identité de l'utilisateur du terminal 100 et traite la requête en fonction de l'identité de l'utilisateur. Ainsi des opérations telles que l'enregistrement de données de suivi, le traitement des données associées à la requête, le contrôle d'accès à partir des données associées à la requête ou la génération de la réponse à la requête, pourront être effectuées en fonction de l'identité de l'utilisateur courant du terminal 100.
En variante, l'étape de détermination de l'identité de l'utilisateur du terminal peut être évitée, si le serveur est conçu pour répondre à la requête sur la seule base de l'identifiant, notamment si le serveur comprend une base de données enregistrant les besoins en configuration de l'utilisateur en association avec l'identifiant.
Par exemple, si la base de donnée 300 comprend une table des services souscrits par les différents utilisateurs, table qui est indexée par un identifiant d'utilisateur, le serveur DHCP identifie à partir de l'identifiant associé à l'utilisateur les services souscrits par cet utilisateur et retourne une réponse (des données de configuration) qui est adaptée par rapport aux services souscrits.
En particulier, la configuration DHCP retournée par le serveur en réponse à une requête "DHCP REQUEST" pourra être fonction de l'identifiant, et donc de l'identité de cet utilisateur. Il est ainsi possible de faire en sorte que le type, statique ou dynamique, de l'adresse retournée, soit lui aussi fonction de l'identité de cet utilisateur. Dans le cas d'exemple où l'utilisateur a besoin d'une adresse statique, le serveur retournera en permanence une adresse statique prédéfinie adaptée aux besoins de cet utilisateur.

Claims

REVENDICATIONS
1. Procédé d'obtention de données de configuration d'un terminal (100), le terminal comprenant un module client DHCP (1 10) apte à communiquer via un réseau (50) avec au moins un module serveur DHCP (210) conformément au protocole DHCP, le procédé comprenant les étapes suivantes: - génération par ledit module client DHCP d'une ou plusieurs requêtes DHCP pour l'obtention de données de configuration dudit terminal,
- transmission desdites une ou plusieurs requêtes DHCP via ledit réseau par ledit module client DHCP audit au moins un module serveur DHCP,
- réception des données de configuration reçues par ledit module client DHCP en réponse à au moins une desdites une ou plusieurs requêtes DHCP, le procédé étant caractérisé en ce qu'il comprend une étape consistant à insérer, dans un champ d'option prédéfini d'au moins une desdites une ou plusieurs requêtes DHCP, des données optionnelles comprenant un identifiant associé, directement ou indirectement, à un seul utilisateur dudit terminal, et en ce que lesdites données de configuration reçues sont personnalisées pour ledit utilisateur.
2. Procédé selon la revendication 1 , caractérisé en ce que le procédé comprend une étape consistant à lire tout ou partie des données optionnelles dans un support personnel d'enregistrement accessible à partir du terminal.
3. Procédé selon la revendication 2, caractérisé en ce que ledit support personnel d'enregistrement est un support dont l'accès est sécurisé par un code d'identification.
4. Procédé selon la revendication 2 ou 3, caractérisé en ce que ledit support personnel d'enregistrement est de type support amovible.
5. Procédé selon l'une quelconque des revendications 2 à 4, caractérisé en ce que ledit support personnel d'enregistrement est intégré dans un terminal mobile et est accessible à partir dudit terminal par un lien local de communication établi entre ledit terminal et ledit terminal mobile.
6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ledit identifiant fait partie du groupe comprenant: - un identifiant dudit utilisateur,
- un identifiant d'immatriculation d'un support personnel d'enregistrement associé audit utilisateur,
- un identifiant d'un objet associé audit utilisateur, - un identifiant d'un service associé audit utilisateur,
- un identifiant de profil utilisateur associé audit utilisateur.
7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que lesdites données optionnelles comprennent en outre des données comprenant une identification d'au moins un service auquel l'utilisateur a souscrit.
8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que tout ou partie des données optionnelles sont insérées dans la requête sous forme chiffrée.
9. Procédé de traitement par un serveur (200) d'une ou plusieurs requêtes DHCP émises par un module client DHCP (1 10) d'un terminal (100) pour l'obtention de données de configuration dudit terminal (100), ledit serveur comprenant un module serveur DHCP (210) apte à communiquer avec ledit module client DHCP (1 10) via un réseau (50) conformément au protocole DHCP, ledit procédé comprenant les étapes consistant à
- générer les données de configuration demandées,
- transmettre audit module client DHCP les données de configuration en réponse à au moins une desdites une ou plusieurs requêtes DHCP, le procédé étant caractérisé en ce qu'au moins une desdites une ou plusieurs requêtes DHCP reçues comprend, dans un champ d'option prédéfini, des données optionnelles comprenant un identifiant associé, directement ou indirectement, à un seul utilisateur dudit terminal et en ce que les données de configuration générées sont personnalisées pour ledit utilisateur.
10. Procédé selon la revendication 9 caractérisé en ce que les données de configuration générées comprennent une adresse IP, dont le type statique ou dynamique est fonction dudit identifiant.
1 1 . Procédé selon la revendication 9 ou 10 caractérisé en ce que le procédé comprend les étapes consistant
- à déterminer l'identité dudit utilisateur à partir dudit identifiant, - à générer les données de configuration demandées en fonction de l'identité dudit utilisateur en cas d'identification de l'utilisateur,
- à refuser la génération des données de configuration demandées dans le cas où ledit utilisateur n'est pas identifié.
12. Procédé selon l'une quelconque des revendications 9 à 1 1 caractérisé en ce que le procédé comprend une étape consistant à enregistrer pour chaque requête comprenant ledit champ d'option prédéfini des données de suivi comprenant des informations de date et/ou heure de réception de ladite requête.
13. Terminal comprenant un module client DHCP, convenant à la mise en œivre du procédé selon l'une quelconque des revendications 1 à 8 et comprenant
- un module pour provoquer l'insertion desdites données optionnelles dans ledit champ d'option prédéfini,
- un module pour provoquer la lecture de tout ou partie desdites données optionnelles dans un support personnel d'enregistrement associé audit utilisateur et accessible à partir du terminal.
14. Serveur comprenant un module serveur DHCP, convenant à la mise en œivre du procédé selon l'une quelconque des revendications 9 à 12, et comprenant un module pour générer lesdites données de configuration demandées en fonction dudit identifiant.
15. Serveur selon la revendication 14, caractérisé en ce qu'il comprend une base de données comprenant une liste d'identifiants, et pour chaque identifiant des données correspondant à une description des besoins en configuration de l'utilisateur associé à cet identifiant.
EP06778966A 2005-06-28 2006-06-22 Procede d'obtention de donnees de configuration pour un terminal par utilisation du protocole dhcp Ceased EP1900179A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0506572A FR2887723A1 (fr) 2005-06-28 2005-06-28 Procede d'obtention de donnees de configuration pour un terminal par utilisation du protocole dhcp
PCT/FR2006/050621 WO2007000552A2 (fr) 2005-06-28 2006-06-22 Procede d'obtention de donnees de configuration pour un terminal par utilisation du protocole dhcp

Publications (1)

Publication Number Publication Date
EP1900179A2 true EP1900179A2 (fr) 2008-03-19

Family

ID=35825368

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06778966A Ceased EP1900179A2 (fr) 2005-06-28 2006-06-22 Procede d'obtention de donnees de configuration pour un terminal par utilisation du protocole dhcp

Country Status (4)

Country Link
US (1) US20080279116A1 (fr)
EP (1) EP1900179A2 (fr)
FR (1) FR2887723A1 (fr)
WO (1) WO2007000552A2 (fr)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8681779B2 (en) * 2006-09-01 2014-03-25 Alcatel Lucent Triple play subscriber and policy management system and method of providing same
US20080259941A1 (en) * 2007-04-19 2008-10-23 At&T Knowledge Ventures, L.P. System and apparatus for managing ip addresses
US9106714B2 (en) * 2009-07-23 2015-08-11 Cisco Technology, Inc. Plug and play provisioning of voice over IP network devices
CN103155495B (zh) * 2011-07-30 2016-06-29 华为技术有限公司 用于路由协议配置的方法、装置及系统
FR3046012A1 (fr) * 2015-12-17 2017-06-23 Orange Procede et dispositif de fourniture d'une information de localisation a un equipement connecte a un point d'acces reseau
FR3057423A1 (fr) * 2016-10-11 2018-04-13 Orange Procede de negociation d'une qualite de service offerte par une passerelle a des terminaux
US10805292B2 (en) * 2018-02-19 2020-10-13 Fmr Llc Secure authentication and network access management for mobile computing devices
US20230086771A1 (en) * 2020-03-13 2023-03-23 Nec Corporation Data management system, data management method, and data management program

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000067446A1 (fr) * 1999-05-03 2000-11-09 Nokia Corporation Mecanisme d'authentification a base de sim pour les messages dhcrv4/v6
US7096273B1 (en) * 2001-04-25 2006-08-22 Cisco Technology, Inc. DHCP over mobile IP
US7720044B1 (en) * 2002-04-19 2010-05-18 Nokia Corporation System and method for terminal configuration
US20040059844A1 (en) * 2002-09-20 2004-03-25 Woodhead Industries, Inc. Network active I/O module with removable memory unit
US7640430B2 (en) * 2005-04-04 2009-12-29 Cisco Technology, Inc. System and method for achieving machine authentication without maintaining additional credentials

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DROMS BUCKNELL UNIVERSITY R: "Dynamic Host Configuration Protocol; rfc2131.txt", IETF STANDARD, INTERNET ENGINEERING TASK FORCE, IETF, CH, 1 March 1997 (1997-03-01), XP015007915, ISSN: 0000-0003 *

Also Published As

Publication number Publication date
US20080279116A1 (en) 2008-11-13
FR2887723A1 (fr) 2006-12-29
WO2007000552A3 (fr) 2007-05-03
WO2007000552A2 (fr) 2007-01-04

Similar Documents

Publication Publication Date Title
US8015253B1 (en) System and method for controlling inter-device media exchanges
EP2294776B1 (fr) Procédé et système d'accès par un utilisateur à au moins un service offert par au moins un autre utilisateur
EP1900179A2 (fr) Procede d'obtention de donnees de configuration pour un terminal par utilisation du protocole dhcp
JP2003527672A (ja) インターネットホストサーバを介してポータブルデバイスの安全な認証を提供するための方法および装置
EP3298812B1 (fr) Chargement de profil d'abonnement dans une carte sim embarquée
FR2977418A1 (fr) Systeme d'authentification via deux dispositifs de communication
WO2008085205A2 (fr) Système et procédé de fourniture de services de prise en charge réseau et infrastructure de prise en charge de passerelle de locaux d'abonnés
WO2009055182A1 (fr) Système et procédé de transfert automatique de données d'un dispositif à un autre
EP2795870B1 (fr) Procede d'acces par un terminal de telecommunication a une base de donnees hebergee par une plateforme de services accessible via un reseau de telecommunications
EP1849320A1 (fr) Procede et dispositif d'acces a une carte sim logee dans un terminal mobile par l'intermediaire d'une passerelle domestique
EP1537718B1 (fr) Serveur de selection automatique d'authentification
EP1704700B1 (fr) Procede et systeme pour l' exploitation d'un reseau informatique destine a la publication de contenu
WO2010006914A1 (fr) Procédé d'authentification d'un utilisateur d'un service sur terminal mobile
WO2006010810A2 (fr) Procede et systeme de certification de l’identite d’un utilisateur
WO2004043093A1 (fr) Systeme et procede de gestion d'acces d'un reseau de communication a un terminal mobile
EP1905217B1 (fr) Procede de configuration d'un terminal a travers un reseau d'acces
WO2018211180A1 (fr) Procede pour connecter des equipements au reseau internet
WO2013110884A1 (fr) Systeme et procede de controle d'une requête dns
FR3114714A1 (fr) Procédé d’accès à un ensemble de données d’un utilisateur.
EP3820112A1 (fr) Procédé de configuration d accès à un service internet
FR2844949A1 (fr) Procede de gestion d'une configuration d'une passerelle par un utilisateur de la passerelle
EP1705868A2 (fr) Procédé et système de partage d'attributs personnels
WO2018211179A1 (fr) Procede pour la creation de comptes d'acces au reseau internet
EP4362391A1 (fr) Procédé de gestion d'accès d'un utilisateur à au moins une application, programme d'ordinateur et système associés
FR2922402A1 (fr) Procede d'acces a un contenu a partir d'un terminal mobile

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20080118

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20080331

RIN1 Information on inventor provided before grant (corrected)

Inventor name: BOURDAIS, FRANCOIS

Inventor name: TUFFIN, STEPHANE

DAX Request for extension of the european patent (deleted)
REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20111022