WO2014001724A1 - Procede d'emission d'un message par un serveur d'un coeur de reseau ip|multimedia ims, et serveur - Google Patents

Procede d'emission d'un message par un serveur d'un coeur de reseau ip|multimedia ims, et serveur Download PDF

Info

Publication number
WO2014001724A1
WO2014001724A1 PCT/FR2013/051504 FR2013051504W WO2014001724A1 WO 2014001724 A1 WO2014001724 A1 WO 2014001724A1 FR 2013051504 W FR2013051504 W FR 2013051504W WO 2014001724 A1 WO2014001724 A1 WO 2014001724A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
server
network
recommendation
message
Prior art date
Application number
PCT/FR2013/051504
Other languages
English (en)
Inventor
Jean-Claude Le Rouzic
José DOREE
Original Assignee
Orange
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 Orange filed Critical Orange
Priority to ES13744647.2T priority Critical patent/ES2694676T3/es
Priority to EP13744647.2A priority patent/EP2868058B1/fr
Priority to US14/411,018 priority patent/US10182037B2/en
Publication of WO2014001724A1 publication Critical patent/WO2014001724A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1073—Registration or de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • 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/14—Session management
    • H04L67/141—Setup of application sessions

Definitions

  • the invention relates to the general field of telecommunications, and more particularly to the field of multimedia Internet Protocol (IP) network architectures, such as in particular network architectures using the technology designated by "voice over IP” (or VoIP for Voice over IP).
  • IP Internet Protocol
  • IP Multimedia Subsystem IP Multimedia Subsystem
  • 3GPP Third Generation Partnership Project
  • SIP Session Initiation Protocol
  • IETF Internet Engineering Task Force
  • the invention can, however, be used in combination with other multimedia IP core network architectures, such as, for example, proprietary architectures, implementing or not the SIP protocol for establishing multimedia sessions (voice, text, video). , data, etc.).
  • multimedia IP core network architectures such as, for example, proprietary architectures, implementing or not the SIP protocol for establishing multimedia sessions (voice, text, video). , data, etc.).
  • the invention relates more specifically to securing communications between a terminal and a multimedia IP core network.
  • IP networks such as VoIP networks based on an IMS architecture.
  • a terminal can be connected and registered with the core network IMS through multiple access networks, such as through a 3GPP access network, xDSL (x Digital Subscriber Line). , EPC (Evolved Packet Core), Wireless Local Area Network (WLAN), Cable, Worldwide Interoperability for Microwave Access (WiMAX), or CDMA2000 (Multiple Access Code Division 2000).
  • 3GPP access network xDSL (x Digital Subscriber Line).
  • EPC Evolved Packet Core
  • WLAN Wireless Local Area Network
  • Cable Worldwide Interoperability for Microwave Access
  • WiMAX Worldwide Interoperability for Microwave Access
  • CDMA2000 Multiple Access Code Division 2000
  • the 3GPP standard in its current definition, provides the possibility of establishing a secure link between a terminal and its connection server to the core network IMS, ie between the terminal and the server P-CSCF (Proxy-Call Session Control Function) associated with it.
  • This secure link also known as the "secure tunnel” or “security association”
  • P-CSCF server and checking the integrity of this data.
  • the parameters of this secure link (security protocol used, encryption or signature algorithms, port numbers used, etc.) are exchanged between the terminal and the server P- CSCF when registering the terminal with the IMS core network.
  • a terminal when a terminal proposes an authentication method including the establishment of a secure tunnel, it issues a registration request including a "header” (field in the registration request) called “Authorization”, and a "security-client” header containing:
  • IPsec protocol is associated with the so-called “IMS AKA” authentication method
  • TLS protocol is associated with the so-called "SIP digest with TLS” authentication method.
  • the impact on the resources of mobile terminals is further accentuated by the fact that the secure tunnel provided by the 3GPP standard is superimposed on the encryption procedures already implemented by some mobile access networks, such as encryption procedures.
  • the SGSN Server GPRS Support Node
  • BTS Base Transceiver Station
  • Node B Node B for the GSM EDGE Radio Access Network (GERAN) user plan and UTRAN (Terrestrial Radio Access Network)
  • MME Mobility Management Entity
  • the data exchanged between the terminal and the multimedia IP core network is encrypted a first time by the encryption procedures set up by the access networks, then the encrypted data. obtained are encrypted a second time in the secure tunnel established between the terminal and the IP multimedia core network.
  • the invention makes it possible to overcome this drawback by proposing a method of sending a message by a server of a multimedia IP core network following the reception by said server of a request for registration of a terminal. at the heart of the network, said registration request proposing an authentication method providing (or equivalent, requiring) the establishment of a secure tunnel between the terminal and a connection entity of this terminal at the heart of the network, said transmitting method comprising:
  • the invention also relates to a server of a multimedia IP core network, this server comprising means activated following the reception by the server of a request for registration of a terminal near the core network, said request registration system proposing an authentication method providing for the establishment of a secure tunnel between the terminal and a connection entity of this terminal at the heart of the network, these means comprising:
  • said authentication method proposed by the terminal may be indicated explicitly, but (as explained below) it will preferably be, in the present state of the 3GPP standards, implicitly indicated.
  • the invention proposes to condition the establishment of the secure tunnel between the terminal and the IP multimedia core network according to at least the access network used by the terminal to register with the core network.
  • the type of access network used by the terminal eg UMTS network, WiFi network, etc.
  • the access network used by the terminal can be taken into account in developing this recommendation, but also other parameters related to this access network, such as by for example, the existence of secure roaming agreements with this access network, the fact that the access network used by the terminal to register with the core network is a visited access network (location of international roaming), or the fact that the access network used by the terminal is or is not in the nominal network (home network) of the server establishing the recommendation, etc.
  • an access network may comprise one or more access (sub) networks.
  • This conditioning is expressed, in accordance with the invention, in the form of a recommendation to establish or not the secure tunnel, issued by a server IP multimedia core network during the registration of the terminal (ie say finally, when the establishment of the secure tunnel is required by the terminal).
  • the recommendation is elaborated by the server, according to the identified access network, preferably taking into account a data security level associated (or assigned) by the multimedia IP core network to the access network used by the terminal.
  • This level of security can depend on several factors, such as the type of access network (eg 3GPP access, WiFi access (Wireless Fidelity), etc.), the existence of strong security procedures implemented on this network, the establishment of roaming agreements secured by the core network with this access network, etc. It reflects the trust that the core IP multimedia network (i.e. the IP multimedia core network operator) has in securing the data exchange provided by the access network. Thus, a multimedia IP core network can associate an access network with a low level of security despite the encryption algorithms implemented by this access network, for example because this access network is associated with a network. sensitive geographical area, etc.
  • the core IP multimedia network i.e. the IP multimedia core network operator
  • This recommendation thus enables the server to indicate a degree of necessity (or obligation) to establish the secure tunnel normally provided by the core network between the terminal and the connection entity, given the level of security guaranteed by the access network according to the IP multimedia core network.
  • the recommendation issued by the server preferably comprises one of the following indications:
  • An indication not to establish the secure tunnel between the terminal and the connection entity for example because the IP core network considers that the access network used by the terminal includes sufficiently strong and reliable encryption procedures for guarantee the protection and integrity of the data transmitted or received by the terminal;
  • an indication of free choice as to the establishment of the secure tunnel between the terminal and the connecting entity An indication to establish the secure tunnel between the terminal and the connection entity, for example because the access network used by the terminal is not considered sufficiently secure in view of certain predetermined criteria (eg absence data encryption, lack of data integrity control, etc.).
  • the server may recommend, in its recommendation, not to establish the secure tunnel between the terminal and the connection, or alternatively, leave free choice in this recommendation to the terminal to establish or not this secure tunnel.
  • the server can then recommend in its recommendation to establish the secure tunnel between the terminal and the connection entity. .
  • the server recommendation can be elaborated by the server by comparing characteristics and / or the type of the access network used by the terminal with respect to predetermined security criteria, to determine whether the level of security provided by the network of access is sufficient to release the constraint of establishing the secure tunnel between the terminal and the connecting entity.
  • the recommendation of the server is developed by consulting a table or a pre-established database, in which is associated with different access networks, a recommendation on the need (or obligation) or not to establish the security tunnel between the terminal and the connecting entity.
  • This table can be filled in by the operator of the multimedia IP core network according to the security level of the exchanges that it associates with the different access networks: this level of security can be established by the operator of the core network, as mentioned above, taking into account in particular the prior knowledge of the security procedures (encryption, integrity control, etc.) implemented on these different access networks (eg depending on the type of network). access and / or the operator of these networks, the definition of the standards respected by these access networks), the existence or not of "strong” (reliable) roaming agreements with the access networks or lack of sufficient information on an access network, etc.
  • the recommendation issued by the server IP multimedia core network thus offers the possibility of avoiding the establishment of a secure link (tunnel) between the terminal and the connection entity when strong protection of data and their integrity is already ensured by the access network used by the terminal.
  • the invention therefore has a preferred but nonlimiting application when the IP multimedia core network implements an IMS architecture, in which the establishment of a secure tunnel during the registration of a terminal is provided according to the 3GPP standard. More generally, it applies to any core IP multimedia network providing for the establishment of a secure tunnel between the terminal and the access core network (when the terminal is registered with the core network ).
  • the server of the multimedia IP network core issuing the recommendation may be an S-CSCF server, and the message in which the recommendation is inserted is then sent by the S-CSCF server to the terminal via a server P - CSCF connecting the terminal to the heart of multimedia IP network.
  • the recommendation developed by the S-CSCF server is preferably inserted in an intermediate response message to the terminal registration request such as an SIP 401 Unauthorized message, sent by the S-CSCF server to the terminal, according to the SIP protocol.
  • the P-CSCF server can then propagate this recommendation to the terminal to inhibit or on the contrary trigger the establishment of the secure tunnel between the terminal and the P-CSCF server.
  • the same S-CSCF server can be in relation with several P-CSCF servers, this variant has the advantage of limiting the complexity related to the implementation of the invention and thus optimizing the operation of the core network (in particular, a single pre-established table needs to be stored at the S-CSCF server to issue recommendations relating to several connection entities).
  • this variant offers the possibility of easily taking into account, in developing the recommendation (or the weighting), information contained in the profile of the user of the terminal. For example, it can be envisaged to associate in the user's profile of the terminal, an indication that for this user, a secure tunnel must always be established, regardless of the security level associated with the access network used by the user. terminal to register.
  • the server of the multimedia IP network core issuing the recommendation may be a P-CSCF server, and the message in which the recommendation is inserted is then sent to the terminal.
  • the recommendation developed by the P-CSCF server is preferably inserted in an intermediate response message to the terminal registration request such as a SIP message 401 Unauthorized sent by the S-CSCF server to the terminal and which passes through the P-CSCF server, according to the SIP protocol.
  • the server issuing the recommendation may be the connection entity itself of the terminal at the heart of multimedia IP network.
  • This variant makes it possible to have a more local management of the establishment of the secure tunnel and to take into account more easily the local specificities of access to the core network (eg presence of certain access networks (eg WiFi) in a particular location).
  • a recommendation is developed in accordance with the invention by both an S-CSCF server and a P-CSCF server of the multimedia IP core network.
  • the recommendations developed respectively by the S-CSCF server and the P-CSCF server are different, only the recommendation issued by the P-CSCF server is taken into account and ultimately transmitted to the terminal.
  • the recommendation issued by the P-CSCF server overwrites the recommendation issued by the S-CSCF server in the intermediate SIP 401 Unauthorized response message.
  • the server according to the invention can be integrated into any entity of the core network capable of receiving requests for registration of the terminals containing a request for establishment of a secure tunnel between the terminal and the terminal. entity connecting this terminal to the network core.
  • the recommendation is developed based also on at least one parameter received with the registration request.
  • This parameter may in particular be contained in the registration request or conveyed in the signaling associated with this registration request.
  • This embodiment makes it possible, for the same access network or for the same type of access network, to weight the conditioning as a function of the access network implemented by the server, by means of the parameter contained in the registration request.
  • This parameter can be in particular a transport IP address of the registration request, that is to say the source address of the registration request of the terminal as received by the server.
  • this source address may, depending on the network configurations envisaged, correspond to the contact address or the IP address of the terminal seeking to register (eg for a network of mobile access), or the IP address of an intermediate entity between the terminal and the server (eg home gateway).
  • this parameter may be an identifier associated with the user of the terminal, such as an International Mobile Subscriber Identity (IMSI) or Mobile Station Integrated Services Digital Network (MSISDN) identifier.
  • IMSI International Mobile Subscriber Identity
  • MSISDN Mobile Station Integrated Services Digital Network
  • a parameter such as an identifier associated with the terminal user makes it possible to weight the recommendation developed with respect to the access network used by the terminal, according to information associated with this identifier. and present especially in the profile of the user.
  • This information includes, for example, the services subscribed to by the user, his preferences, his membership in a category of sensitive subscribers for whom a secure link must always be implemented, etc.
  • the message sent is in accordance with the SIP protocol, and the recommendation of the server is inserted in a "Security Server" field of this message.
  • This embodiment makes it possible to interface easily with the existing SIP standard, by adding an appropriate parameter in the "Security Server" field defined by the 3GPP standard in Appendix H of the specification document TS 33.203, for inform the terminal or the connecting entity that the implementation of a secure tunnel must (or can) or not take place.
  • the message sent by the server also contains information enabling the establishment of the secure tunnel between the terminal and the connection entity.
  • This embodiment is compatible with terminals that are not able to interpret and / or execute the recommendation issued by the server.
  • Such a terminal can thus, regardless of the opinion issued by the server and the security provided by the access network, establish a secure link from the information contained in the message, so as to ensure the protection and integrity data exchanged with the core network.
  • this information can also be used when the recommendation issued by the server leaves a free choice as to the establishment or not of the secure tunnel.
  • the efficiency of the invention in reducing the complexity and the extra cost of resources resulting from the existence of a double encryption of data rests on the one hand, on the server that issues the recommendation as to the establishment or not of the secure tunnel according to the access network used by the terminal, and secondly, on the terminal read itself, since it is able to execute the recommendation issued by the server when registering with the core network.
  • the invention also relates to a method of registering a terminal with an IP core network, this method comprising: A step of transmission, by the terminal, of a registration request to the core network, via an access network, said registration request proposing an authentication method providing for the establishment of a tunnel secure between the terminal and a connection entity of this terminal at the heart of the network;
  • the invention also provides a terminal comprising:
  • the registration method and the terminal have the same advantages as those mentioned above for the method of sending a message and the server.
  • connection entity of a terminal to a multimedia IP core network this connection entity comprising:
  • Means for transmitting this recommendation to the terminal Means for transmitting this recommendation to the terminal.
  • the invention also relates to a transmission method intended to be implemented by a connection entity of a terminal to a multimedia IP core network, this transmission method comprising: A step of receiving a request for registration of the terminal at the heart of the network, via an access network, said registration request proposing an authentication method providing for the establishment of a secure tunnel between said terminal; and said connecting entity;
  • connection entity thus relays the recommendation issued by the multimedia IP core network server to the terminal so that the terminal applies this recommendation.
  • the connection entity may just include the recommendation in a message sent to the terminal (ex. in a parameter of the Security Server field of a SIP message), or on the contrary modify the actual form of this recommendation, for example by not sending the information necessary for the establishment of the tunnel if the recommendation issued by the server is not to establish the tunnel between the terminal and the connecting entity.
  • the various steps of the method of transmitting a message and / or the recording method and / or the transmission method are determined by instructions of computer programs.
  • the invention also relates to a computer program on an information carrier, this program being capable of being implemented in a server or more generally in a computer, this program comprising instructions adapted to the implementation of steps of a method of transmitting a message as described above.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in a terminal or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of a recording method as described above.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in a connection entity or more generally in a computer, this program comprising instructions adapted to the implementation steps of a transmission method as described above.
  • These programs can use any programming language, and be in the form of source codes, object codes, or intermediate codes between source code and code object, such as in a partially compiled form, or in any other desirable form.
  • the invention also relates to a computer-readable information medium, comprising instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • the invention also relates to a communication system comprising:
  • a server of a multimedia IP core network according to the invention.
  • a terminal able to register with the multimedia network core by sending a registration request to the core network via an access network
  • a connection entity of the terminal at the heart of the multimedia IP network is a connection entity of the terminal at the heart of the multimedia IP network
  • the terminal being able to execute a recommendation elaborated by the server as to the establishment or not of a secure tunnel between the terminal and the connection entity of the terminal at the heart of the network.
  • the communication system according to the invention makes it possible to relax the constraint of establishing the secure tunnel between the terminal and the connection entity when a sufficient level of security of exchanges is associated with the access network by the heart of the multimedia IP network. In this way, the resources of the terminal and the connection entity are saved.
  • the message transmission method, the recording method, the transmission method, the server, the terminal, the connection entity and the transmission system present in combination all or part of the aforementioned characteristics.
  • FIG. 1 shows, schematically, a communication system, a server, a connection entity and a terminal according to the invention, in a first embodiment
  • FIGS. 2A, 2B and 2C show, schematically, the respective hardware architectures of the terminal, the server and the connection entity of FIG. 1, in the first embodiment;
  • FIG. 3 represents, in the form of flow charts, the main steps of a recording method, a transmission method and a method of sending a message as they are respectively implemented; by the terminal, the connection entity and the server of FIG. 1 in the first embodiment;
  • FIG. 4 illustrates a table associating with different access networks, a recommendation as to the establishment of a secure link, and used by the server of FIG. 1 to formulate its recommendation in the first embodiment
  • FIG. 5 shows, schematically, a communication system, a server and a terminal according to the invention, in a second embodiment
  • FIG. 6 schematically shows the hardware architecture of the server of Figure 5;
  • FIG. 7 represents, in the form of flow charts, the main steps of a recording method and of a method of sending a message as they are implemented by the terminal and the server respectively.
  • Figure 5 in the second embodiment - Appendix 1 gives examples of requests for registration of the terminal of Figure 1 and messages containing a recommendation issued by the server of Figure 1, in the first embodiment; and
  • Appendix 2 gives examples of a request for registration of the terminal of Figure 5 and a message containing a recommendation issued by the server of Figure 5, in the second embodiment.
  • FIG. 1 represents, in its environment, a communication system 1 according to the invention, in a first embodiment.
  • the communication system 1 comprises a terminal 2 according to the invention, able to register with a CN heart of multimedia IP network via an access network AN.
  • terminal 2 can be both a mobile terminal, such as a smartphone (or smartphone), a laptop, or a personal digital assistant (or PDA for Personal Digital Assistant), that of a fixed terminal.
  • a mobile terminal such as a smartphone (or smartphone), a laptop, or a personal digital assistant (or PDA for Personal Digital Assistant), that of a fixed terminal.
  • PDA Personal Digital Assistant
  • the terminal 2 has the hardware architecture of a computer, as schematically illustrated in FIG. 2A.
  • It comprises a processor 2A, a random access memory 2B, a read-only memory 2C, a non-volatile flash memory 2D, as well as communication means 2E implementing in particular the SIP protocol and allowing it to communicate via the AN access network.
  • the communication means 2E allow the terminal 2 to communicate in particular with the entities of the core network CN.
  • the read-only memory 2C of the terminal 2 constitutes a recording medium in accordance with the invention, readable by the processor 2A and on which is recorded a computer program according to the invention, comprising instructions for executing the steps of FIG. a method of registering with the CN core network according to the invention, described later with reference to FIG.
  • CN network used by the terminal 2 to connect and register with the CN core network, as this access network is known to the core of the network.
  • This access network can thus be, for example, a 3GPP access network, an xDSL access network, an EPC access network, etc. It can be managed by the same operator as the CN core network or by a separate operator.
  • the core of the CN network is based on an IMS architecture, implementing the SIP protocol, as described in the specification document TS23.228 of the 3GPP standard, entitled "IP Multimedia Subsystem; Stage 2 ", Release 9, September 2010, available at www.3qpp.org.
  • a core network implementing an IMS architecture comprises several functional entities including, in particular, a CSCF entity (Call Session Control Function) composed of several servers, among which:
  • CSCF entity Call Session Control Function
  • An S-CSCF server (Serving-Call Session Control Function), in charge in particular of the registration of terminals on the core network;
  • a P-CSCF server (Proxy Call Session Control Function), acting as a terminal connection entity with the core network.
  • the core network CN comprises a server
  • the P-CSCF 3 entry point of the terminal 2 on the core network CN, and an S-CSCF server 4, responsible for the registration of the terminal 2 at the core network CN.
  • the registration requests to the CN core network sent by the terminal 2 pass through the P-CSCF server 3 before being routed for processing to the S-CSCF server 4.
  • the 3GPP standard provides (requires), depending on the type of terminal and the type of SIM card (Subscriber Identity Module) equipping the terminal (presence of a USIM card (Universal Subscriber Identity Module) or ISIM (International Subscriber Identity) Module)), when registering a terminal with an IMS backbone (and thus with the CN core network), establishing a secure tunnel between the terminal and the connection entity of the network.
  • SIM card Subscriber Identity Module
  • USIM Universal Subscriber Identity Module
  • ISIM International Subscriber Identity
  • secure tunnel established between two entities eg a terminal and a P-CSCF server
  • two entities eg a terminal and a P-CSCF server
  • a secure link established between the two entities ensuring, by means of appropriate keys, the encryption and / or the integrity of the data exchanged between these two entities.
  • the invention advantageously proposes, in order to preserve the resources of the terminal and the P-CSCF server, to condition the establishment of this secure tunnel as a function of at least the access network used by the terminal.
  • the invention is not limited to an IMS type architecture. It can indeed be applied to other architectures IP Multiplia core network providing for the establishment of a secure tunnel when registering a terminal, such as including proprietary architectures.
  • the conditioning of the establishment of the secure tunnel between the terminal 2 and the P-CSCF server 3 is carried out via a recommendation developed by the S-CSCF server 4.
  • the S-CSCF server 4 of the CN core network thus integrates, on the one hand, the functionalities of an S-CSCF server as defined by the 3GPP standard, and, on the other hand, the characteristics of a server of the communication system 1 according to the invention.
  • the server S-CSCF 4 here has the hardware architecture of a computer, as schematically illustrated in Figure 2B.
  • a processor 4A it comprises in particular a processor 4A, a RAM 4B, a read-only memory 4C, a non-volatile flash memory 4D as well as communication means 4E implementing in particular the SIP protocol.
  • These communication means allow it to communicate with the entities of the CN core network and with the terminal 2.
  • the read-only memory 4C of the S-CSCF server 4 constitutes a recording medium in accordance with the invention, readable by the processor 4A and on which is recorded a computer program according to the invention, comprising instructions for execution. steps of a message transmission method according to the invention described later with reference to FIG.
  • the recommendation developed by the S-CSCF server 4 as to the establishment or not of the secure tunnel between the terminal 2 and the P-CSCF server 3 is relayed by the P-CSCF server 3 to the terminal 2.
  • the P-CSCF server 3 integrates not only the functionalities of a P-CSCF server as defined by the 3GPP standard, but also the characteristics of a connection entity according to the invention.
  • the server P-CSCF 3 here has the hardware architecture of a computer, as schematically illustrated in Figure 2C.
  • the ROM 3C P-CSCF server 3 is a recording medium according to the invention, readable by the processor 3A and on which is recorded a computer program according to the invention, including instructions for execution steps of a transmission method according to the invention, now described with reference to FIG.
  • the terminal 2 wishes to register with the heart network CN, via the access network AN, for example to access multimedia services managed by the core network CN.
  • the terminal 2 transmits, via its communication means 2E, a REGI registration request to the core network CN (step E10).
  • this REGI registration request is a SIP REGISTER request.
  • appendix 1 An example of such a request is given in appendix 1 (see example Ex.
  • it comprises, in a known manner, a user identifier of the terminal 2 in the "From" and “To” fields, as well as information relating to the access network AN used by the terminal 2 to register with CN network core. This information is in the "P-Access-Network-Info" field of the REG request.
  • AN is a 3GPP-UTRAN-TDD access network.
  • the request REGI sent by the terminal 2 also contains information relating to the establishment of a secure tunnel with the server P-CSCF 3 of the heart network CN, according to the standard 3GPP. This information is contained in the "Security-Client" field of the registration request.
  • the secure tunnel proposed by the terminal will be IPsec type for AKA IMS authentication, and TLS type for SIP digest authentication with TLS.
  • the information "ipsec-3gpp" indicates that it is the IPsec protocol.
  • Said information may also include the encryption and integrity control algorithms envisaged (in example Ex.
  • the REGI registration request is received by the P-CSCF server 3 connecting the terminal 2 to the core network CN (step F10).
  • the P-CSCF server 3 Upon receipt of this request, the P-CSCF server 3 identifies which access network AN is used by the terminal 2 to register with the core network CN (step F20).
  • the access network information, included by the terminal 2 in its REGI registration request, is not necessarily reliable, so that the P-CSCF server 3 here determines on its own which AN access network borrows the terminal 2.
  • IP addresses correspond to transport IP addresses that can be used to carry requests from terminals seeking to connect to the CN core network (and thus to register with the CN core network). Depending on the envisaged network configurations, it may be the IP addresses or contact addresses of the terminals seeking to connect, or intermediate entity IP addresses between these terminals and the P-CSCF server 3.
  • Such a table can be easily established by the CN core network operator, for each access network known to the operator (at each new installation of an access network for example).
  • the P-CSCF server 3 initially determines, according to means known to those skilled in the art, the transport IP address of the REGI registration request that it received (i.e. the source IP address of the REGI request as received by the P-CSCF server 3).
  • step F20 it compares this transport IP address with the IP address ranges entered in the lookup table. It thus deduces the access network AN used by the terminal 2 to register (step F20).
  • the P-CSCF server 3 replaces, if necessary, the information contained in the "P-Access-Network-Info" field of the REGI registration request, by the network AN obtained using the transport IP address. of the REGI request (step F30).
  • the information contained in the P-Access-Network-Info field, following this modification, is a network information certified by the P-CSCF 3 server.
  • the P-CSCF server 3 also modifies certain fields of the request, in a manner known per se, in accordance with the 3GPP standard. For example, it deletes the "Security-Client" field from the request.
  • the registration request of the terminal modified by the P-CSCF server 3 is then transmitted using its communication means 3E to the S-CSCF server 4, in the form of a request REG2 (step F40).
  • the request REG2 is, despite the modifications made to the request REGI received from the terminal 2, a request for registration of the terminal 2 within the meaning of the invention.
  • an example of a REG2 request derived from the REGI request given in Example Ex. 1 is provided in Example Ex. 2.
  • the S-CSCF server 4 On receipt of the registration request REG2 from the terminal 2 (step G10), the S-CSCF server 4 identifies the access network AN used by the terminal 2 to register, by consulting the "P-Access-Network" field. -Info "of the request, positioned by the P-CSCF server 3 (step G20).
  • step G30 it elaborates a RECO recommendation as to the establishment or not of the secure tunnel between the terminal 2 and the P-CSCF server 3 (step G30).
  • This recommendation reflects the timeliness (ie useful or mandatory) of establishing the secure tunnel between the terminal 2 and the P-CSCF 3 server so as to ensure the protection and integrity of the data exchanged between the terminal 2 and the core network CN.
  • This recommendation is elaborated here taking into account a level of data security associated by the multimedia IP core network to the access network used by the terminal.
  • the S-CSCF server 4 uses a pre-established table (or database) T, in which various access networks are associated with a recommendation on the necessity or otherwise of establish the security tunnel between the terminal and the connecting entity.
  • the table T is for example stored in the non-volatile memory 4D of the S-CSCF server 4.
  • This table T is entered here by the CN core network operator, depending on the level of security exchanges (eg insufficient or weak versus sufficient or strong) that it associates with the different access networks.
  • level of security exchanges eg insufficient or weak versus sufficient or strong
  • a recommendation not to establish a secure tunnel is associated in the table T to this access network.
  • a recommendation to establish the secure tunnel is associated in the table T to this access network.
  • the security level of an access network can be established by the operator, taking into account in particular the prior knowledge of the security procedures (encryption, integrity control, etc.) implemented on these different networks.
  • access networks eg depending on the type of access network and / or the operator of these networks, the definition of the standards respected by these access networks), the existence or not of 'strong' (reliable) roaming with access networks, or lack of sufficient information on the security procedures implemented by an access network, etc.
  • FIG. 4 An example of such a table T is illustrated in FIG. 4.
  • a 3GPP-UTRAN-TDD access network and a 3GPP-UTRAN-FDD access network are associated with a recommendation not to establish a secure tunnel between the terminal 2 and the P-CSCF 3 server (recommendation "Not required"), while associating with a public WiFi access network, a recommendation to establish the secure tunnel ("Required” recommendation ).
  • a recommendation not to establish a secure tunnel between the terminal 2 and the P-CSCF 3 server recommendation "Required” recommendation
  • we Implicitly associates in this table a strong security level to the 3GPP-UTRAN-TDD and 3GPP-UTRAN-FDD access networks, and a low level of security to the public WiFi access network.
  • the AN access network used by the terminal 2 is a 3GPP-UTRAN-TDD access network. It is associated with a RECO recommendation not to establish the secure tunnel between the terminal 2 and the P-CSCF 3 server.
  • the S-CSCF server 4 inserts the RECO recommendation obtained by consulting the table T from the access network AN in an M1 message destined for the terminal 2 (step G40).
  • the message M1 is a SIP message 401 Unauthorized intermediate response to the registration request of the terminal 2, which passes through the P-CSCF server 3, according to the SIP protocol.
  • CSCF 4 is given in Annex 1 (see example Ex.3).
  • the recommendation is inserted into this example in the Security-Server header (see Appendix H of the TS 33.203 specification) of the SIP message Ml, using a tunnel parameter set to the value "not_required”.
  • the P-CSCF server 3 receives the message Ml containing the recommendation RECO of the server S-CSCF 4 as for the establishment of the secure tunnel with the terminal 2 (step F50).
  • the message M2 derived from the message Ml received from the server S-CSCF 4 (step F60).
  • the message M2 is therefore also a SIP message 401 Unauthorized.
  • the message M2 also contains information enabling the establishment of the secure tunnel between the terminal 2 and the P-CSCF server 3, regardless of the content of the RECO recommendation.
  • the P-CSCF server 3 ensures that if the terminal 2 is not capable of executing the RECO recommendation, the tunnel will be established in accordance with this information, and the protection of the data exchanged between the terminal 2 and the core network CN will be ensured.
  • an M2 message containing the RECO recommendation of the S-CSCF server 4 is given in Appendix 1 (see Ex.
  • the terminal 2 interprets and executes the recommendation RECO contained in the message M2 (step E30): in other words, it does not establish a tunnel with the P-CSCF server 3.
  • the recommendation developed by the S-CSCF server 4 thus makes it possible to block the establishment of the tunnel initially planned by the core network CN, and thus to preserve the resources of the terminal 2 and the server P-CSCF 3.
  • the registration of the terminal 2 at the core network CN then continues in a manner known per se.
  • the recommendation to establish or not the secure tunnel between the terminal 2 and its CN network core connection entity is developed by the S-CSCF server 4 .
  • FIG. 5 represents, in its environment, a communication system according to the invention, in this second embodiment.
  • the communication system comprises a terminal 2 'according to the invention, able to register with a core CN' IP multimedia network via an access network AN '.
  • no limitation is attached to the nature of the terminal 2 'and the access network AN' used by the terminal 2 'to register and connect to the core network CN'.
  • the terminal 2 ' has a hardware architecture identical to that of the terminal 2, illustrated in Figure 2A described above. Its read-only memory constitutes a recording medium in accordance with the invention, readable by the processor of the terminal 2 'and on which is recorded a computer program according to the invention, comprising instructions for the execution of the steps of a method of registering with the core network CN 'according to the invention, described later with reference to FIG. 7.
  • the network core CN ' here is based on an IMS architecture and comprises a P-CSCF server 3', entry point of the terminal 2 'on the network core CN', and an S-CSCF server 4 ', loaded with the terminal 2 'registration with the core network CN'.
  • CN 'core network requires the establishment of a secure tunnel between the terminal 2' and the connection entity of this terminal to the heart network, otherwise said, between the terminal 2 'and the P-CSCF server 3' associated with this terminal.
  • the P-CSCF server 3 here has the hardware architecture of a computer, as schematically illustrated in FIG. It comprises in particular a processor 3A ', a random access memory 3B', a read-only memory 3C, a non-volatile flash memory 3D 'as well as communication means 3E' implementing, in particular, the SIP protocol. These communication means allow it to communicate with the network core entities CN 'and with the terminal 2'.
  • the ROM 3C P-CSCF server 3 ' is a recording medium according to the invention, readable by the processor 3A' and on which is recorded a computer program according to the invention, comprising instructions for the execution of the steps of a message transmission method according to the invention now described with reference to FIG.
  • FIG. 7 illustrates the main steps of a recording method and a message transmission method implemented respectively by the terminal 2 'and by the P-CSCF server 3' in the second embodiment. .
  • the terminal 2 wishes to register with the core network CN', via the access network AN ', to access for example multimedia services managed by the core network CN'.
  • the terminal 2 transmits, via its communication means 2E', a registration request REGI 'to the core network CN' (step ElO -
  • This registration request REGI ' is a request SIP REGISTER.
  • Appendix 2 An example of such a request is given in Appendix 2 (see example Ex. It includes in particular a user identifier of the terminal 2 'in the fields "From" and "To", as well as information relating to the access network AN' used by the terminal 2 'to register with the heart CN 'network. This information is in the "P-Access-Network-Info" field of the REGI request.
  • AN ' is a 3GPP-UTRAN-TDD type access network.
  • the request REGI 'sent by the terminal 2' also contains information relating to the establishment of a secure tunnel with the P-CSCF server 3 'of the core network CN', according to the standard 3GPP, in the field "Security- Customer "of the registration request.
  • the secure tunnel proposed by the terminal will be IPsec type for AKA IMS authentication, and TLS type for SIP digest authentication with TLS.
  • the information "ipsec-3gpp" indicates that it is the IPsec protocol.
  • Said information may also include the encryption and integrity control algorithms envisaged (in example Ex. 1, these are the known algorithms "hmac-shal-96" and “des-ede3-cbc”), the ports on which the tunnel is to be mounted, etc.
  • the registration request REGI ' is received by the server P-CSCF 3' connecting the terminal 2 'to the core network CN' (step FlO -
  • the P-CSCF server 3 ' On receipt of this request, the P-CSCF server 3 'identifies which access network AN' is used by the terminal 2 'to register with the core network CN' (step F20.) It proceeds, for this purpose, identically to the P-CSCF server 3 in step F20 of the first embodiment, using the transport IP address of the REGI request it has received.
  • the server P-CSCF3 'elaborates, according to the identified access network AN', a recommendation RECO 'as to the establishment or not of the secure tunnel with the terminal 2' (step F30 As previously described, this recommendation translated the timeliness (that is to say, useful or mandatory) of the establishment of the secure tunnel between the terminal 2 'and the P-CSCF server 3' so as to guarantee the protection and integrity of the data exchanged between the terminal 2 'and the core network CN'.
  • This recommendation is developed identically to the recommendation RECO elaborated by the server S-CSCF 4 in the first embodiment (see step G30 previously described), using the table T, which is, in the second embodiment, stored in the non-volatile 3D memory of the P-CSCF 3 server.
  • the access network AN 'used by the terminal 2' is a 3GPP-UTRAN-TDD access network. It is associated, in the table T, with a recommendation not to establish the secure tunnel between the terminal 2 'and the server P-CSCF 3'.
  • the P-CSCF server 3 inserts the RECO recommendation' obtained by consulting the table
  • the message M2 ' also contains information enabling the establishment of the secure tunnel between the terminal 2' and the P-CSCF server 3 ', regardless of the content of the RECO' recommendation.
  • the P-CSCF server 3 ' ensures that if the terminal 2' is not able to execute the RECO recommendation ', the tunnel will be established in accordance with this information, and the protection of the data exchanged between the terminal 2 'and the heart network CN' will be ensured.
  • the terminal 2' Upon receipt of the message M2 '(step E20, the terminal 2' interprets and executes the recommendation RECO 'contained in the message M2' (step E30: in other words, in the example under consideration, it does not establish a tunnel with the server P-CSCF 3 'The registration of the terminal 2' near the core network CN 'continues in a manner known per se.
  • the S-CSCF 4 and P-CSCF 3 'servers use to develop their recommendation, a pre-established table T associating with various access networks, a recommendation as to the establishment or not of a secure tunnel between the terminal and the P-CSCF server connecting the terminal to the network core.
  • this table T implicitly takes into account the security levels associated by the core network to the different access networks.
  • the recommendation can be developed upon receipt of the terminal registration request by dynamically comparing the characteristics and / or the type of access network used by the terminal with respect to predetermined security criteria so as to associate firstly to the access network a level of data security, then to determine if the level of security provided by the access network is sufficient to relax the constraint establishing the secure tunnel between the terminal and the entity connection.
  • the table T only the type strictly speaking of the access network used by the terminal to register with the core network is ultimately taken into account.
  • the operator of the access network used by the terminal in particular to determine whether it is the same operator as the operator network core or trusted operator
  • other information relating to the access network for example if the network used by the terminal is its nominal network or a visited network, or if the network visited and used by the terminal is the network of the server developing the recommendation or another network, etc.
  • the recommendation in addition to the access network used by the terminal, other "discriminant" factors having an influence on the security level. provided by the access network, such as for example the location of the terminal, its user, etc.
  • the access network such as for example the location of the terminal, its user, etc.
  • certain parameters contained in fields of the registration request of the terminal or received with the registration request in particular in the signaling associated with this request, such as, for example, the IP address of the terminal. transport IP address of the registration request, the identifier of the user of the terminal or the encryption algorithms requested in the registration request by the terminal (in the Security Client field), and fill in the table T so that it translates various recommendations concerning the establishment of the secure tunnel according to these parameters as well.
  • a "Not required” recommendation for all users of terminals seeking to register with the core network, with the exception of some users for which a "Required” recommendation will be developed.
  • These users can be identified by the server according to the invention, for example by consulting their user profile stored at the HSS (Home Subscriber Server) of the core network and in which an appropriate indication has been entered.
  • an indication may be included in the table T specifying the existence of such users for which the recommendation established according to the type of access network must be weighted according to the identifier of the user of the terminal.
  • the access network used by the terminal has been preferred as the main criterion for developing the recommendation to establish or not the secure tunnel, and possibly to consider other parameters such as the identity of the user of the terminal seeking to register. However, it is possible to reverse this order of priority, or even consider only one of these parameters as the only criterion for developing the recommendation to establish or not the secure tunnel.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Procédé d'émission d'un message par un serveur d'un cœur de réseau IP multimédia, et serveur L'invention vise un procédé d'émission d'un message (M1) par un serveur (4) d'un cœur de réseau IP multimédia (CN) suite à la réception (G10,F10') par ledit serveur d'une requête d'enregistrement (REG2,REG1') d'un terminal (2, 2') auprès du cœur de réseau, ladite requête d'enregistrement proposant une méthode d'authentification prévoyant l'établissement d'un tunnel sécurisé entre le terminal et une entité de raccordement (3) de ce terminal au cœur de réseau, ce procédé d'émission comprenant: ¾ une étape d'identification d'un réseau d'accès (AN) utilisé par le terminal pour s'enregistrer auprès du cœur de réseau IP multimédia; ¾ une étape d'élaboration, en fonction du réseau d'accès identifié, d'une recommandation (RECO) quant à l'établissement ou non du tunnel sécurisé entre le terminal et l'entité de raccordement pour ladite méthode d'authentification; et ¾ une étape d'insertion de cette recommandation dans le message émis par le serveur.

Description

PROCEDE D'EMISSION D'UN MESSAGE PAR UN SERVEUR D'UN COEUR DE RESEAU IPjMULTIMEDIA IMS, ET SERVEUR
Arrière-plan de rinvention
L'invention se rapporte au domaine général des télécommunications, et plus particulièrement au domaine des architectures de réseau IP (Internet Protocol) multimédia, telles que notamment des architectures de réseau utilisant la technologie désignée par "voix sur IP" (ou VoIP pour Voice over IP).
Elle a une application privilégiée mais non limitative dans le contexte de cœurs de réseau IP multimédia s'appuyant sur une architecture IMS (IP Multimedia Subsystem), telle que proposée par le standard 3GPP (Third Génération Partnership Project), et mettant en œuvre le protocole d'initiation de sessions multimédia SIP (Session Initiation Protocol). Le protocole SIP, défini par le standard IETF (Internet Engineering Task Force), est décrit en détail dans le document RFC 3261 intitulé « SIP: Session Initiation Protocol », Juin 2002, édité par l'IETF.
L'invention peut toutefois être utilisée en association avec d'autres architectures de cœurs de réseau IP multimédia, telles que par exemple des architectures propriétaires, mettant en œuvre ou non le protocole SIP pour l'établissement de sessions multimédia (voix, texte, vidéo, données, etc.).
L'invention concerne plus précisément la sécurisation des communications entre un terminal et un cœur de réseau IP multimédia.
Les opérateurs téléphoniques ont aujourd'hui débuté la migration de leurs réseaux téléphoniques à commutation de circuits vers des réseaux de voix sur IP à commutation de paquets, tels que par exemple des réseaux VoIP s'appuyant sur une architecture IMS.
Dans ces réseaux VoIP, un terminal peut être connecté et enregistré auprès du cœur de réseau IMS par le biais de plusieurs réseaux d'accès, comme notamment par l'intermédiaire d'un réseau d'accès 3GPP, xDSL (x Digital Subscriber Line), EPC (Evolved Packet Core), WLAN (Wireless Local Area Network), câble, WiMAX (Worldwide interoperability for Microwave Access) ou CDMA2000 (Code Division Multiple Access 2000).
Le standard 3GPP, dans sa définition actuelle, prévoit la possibilité d'établir un lien sécurisé entre un terminal et son serveur de raccordement au cœur de réseau IMS, autrement dit, entre le terminal et le serveur P-CSCF (Proxy-Call Session Control Function) qui lui est associé. Ce lien sécurisé, aussi connu sous le nom de « tunnel sécurisé » ou « d'association de sécurité » (« security association » en anglais), se traduit par l'encryptage (i.e. le chiffrement) des données véhiculées entre le terminal et le serveur P-CSCF, et le contrôle de l'intégrité de ces données. Comme décrit dans les spécifications RFC 3329 et TS 33.203 du 3GPP, les paramètres de ce lien sécurisé (protocole de sécurisation utilisé, algorithmes de chiffrement ou de signature, numéros de ports utilisés, etc.) sont échangés entre le terminal et le serveur P-CSCF lors de l'enregistrement du terminal auprès du cœur de réseau IMS. Une fois ce lien sécurisé établi, il existe une association de sécurité entre le terminal et le serveur P-CSCF qui offre une garantie contre l'espionnage des données émises ou reçues par le terminal.
Plus précisément, lorsqu'un terminal propose une méthode d'authentification comprenant l'établissement d'un tunnel sécurisé, il émet une requête d'enregistrement comprenant un « header » (champ dans la requête d'enregistrement) appelé « Authorization », ainsi qu'un header « security-client » contenant :
- soit la valeur « ipsec-3gpp », associée au protocole IPsec (Internet Protocol security) (cf. la Section 5.1.1.2.2 de la spécification TS 24.229),
- soit la valeur « tls », associée au protocole TLS (Transport Layer Security) (cf. la Section 5.1.1.2.4 de la spécification TS 24.229),
qui sont les deux mécanismes de tunnel sécurisé prévus par le 3GPP (cf. l'Annexe H de la spécification TS 33.203). Le protocole IPsec est associé à la méthode d'authentification dite « IMS AKA », et le protocole TLS est associé à la méthode d'authentification dite « SIP digest with TLS ».
Or l'établissement et le maintien d'un tel tunnel sécurisé est relativement coûteux en termes de ressources, tant au niveau des terminaux qu'au niveau des serveurs P-CSCF. Les algorithmes de chiffrement consomment en effet beaucoup de ressources CPU (Central Processing Unit), ce qui a un impact sur la durée de vie des batteries des terminaux mobiles, et nécessite de dimensionner en conséquence les serveurs P-CSCF.
L'impact sur les ressources des terminaux mobiles est en outre accentué par le fait que le tunnel sécurisé prévu par le standard 3GPP vient se superposer aux procédures de chiffrement déjà mises en œuvre par certains réseaux d'accès mobiles, telles que les procédures de chiffrement prévues pour protéger les informations transmises par les terminaux mobiles vers les nœuds SGSN (Serving GPRS Support Node) pour le plan de contrôle et BTS (Base Transceiver Station) ou Node B pour le plan usager des réseaux GERAN (GSM EDGE Radio Access Network ) et UTRAN (UMTS Terrestrial Radio Access Network), ou vers les entités MME (Mobility Management Entity) pour le plan de contrôle et e-NodeB pour le plan usager des réseaux LTE (Long Term Evolution).
En d'autres mots, pour ces réseaux d'accès, les données échangées entre le terminal et le cœur de réseau IP multimédia sont chiffrées une première fois par les procédures de chiffrement mises en place par les réseaux d'accès, puis les données chiffrées obtenues sont chiffrées une seconde fois dans le tunnel sécurisé établi entre le terminal et le cœur de réseau IP multimédia.
Il convient de noter d'autre part, qu'un même terminal sera amené à établir plusieurs canaux de communication sur le plan usager en fonction des services utilisés (Internet, Voix sur LTE,...), et pour chacun d'entre eux, un tunnel sécurisé pourrait être installé entre le terminal et le réseau d'accès. Ce multiple chiffrement des données, s'il garantit une protection maximale des données émises ou reçues par les terminaux, réduit également considérablement l'autonomie des terminaux. Objet et résumé de l'invention
L'invention permet de pallier notamment à cet inconvénient en proposant un procédé d'émission d'un message par un serveur d'un cœur de réseau IP multimédia suite à la réception par ledit serveur d'une requête d'enregistrement d'un terminal auprès du cœur de réseau, ladite requête d'enregistrement proposant une méthode d'authentification prévoyant (ou de façon équivalente, requérant) l'établissement d'un tunnel sécurisé entre le terminal et une entité de raccordement de ce terminal au cœur de réseau, ledit procédé d'émission comprenant :
— une étape d'identification d'un réseau d'accès utilisé par le terminal pour s'enregistrer auprès du cœur de réseau ;
— une étape d'élaboration, en fonction du réseau d'accès identifié, d'une recommandation quant à l'établissement ou non du tunnel sécurisé entre le terminal et l'entité de raccordement pour ladite méthode d'authentification ; et
— une étape d'insertion de cette recommandation dans le message émis par le serveur.
Corrélativement, l'invention vise également un serveur d'un cœur de réseau IP multimédia, ce serveur comprenant des moyens activés suite à la réception par le serveur d'une requête d'enregistrement d'un terminal auprès du cœur de réseau, ladite requête d'enregistrement proposant une méthode d'authentification prévoyant l'établissement d'un tunnel sécurisé entre le terminal et une entité de raccordement de ce terminal au cœur de réseau, ces moyens comprenant :
— des moyens d'identification d'un réseau d'accès utilisé par le terminal pour s'enregistrer auprès du cœur de réseau ;
— des moyens d'élaboration, en fonction du réseau d'accès identifié, d'une recommandation quant à l'établissement ou non du tunnel sécurisé entre le terminal et l'entité de raccordement pour ladite méthode d'authentification ;
— des moyens d'insertion de cette recommandation dans un message ; et
— des moyens d'émission de ce message.
On notera que ladite méthode d'authentification proposée par le terminal peut être indiquée de manière explicite, mais (comme expliqué plus bas) elle sera préféra blement, en l'état actuel des normes 3GPP, indiquée de manière implicite.
Ainsi, l'invention propose de conditionner l'établissement du tunnel sécurisé entre le terminal et le cœur de réseau IP multimédia en fonction au moins du réseau d'accès utilisé par le terminal pour s'enregistrer auprès du cœur de réseau. Notamment, on peut prendre en compte pour élaborer cette recommandation le type du réseau d'accès utilisé par le terminal (ex. réseau UMTS, réseau WiFi, etc.), mais également d'autres paramètres liés à ce réseau d'accès comme, par exemple, l'existence d'accords d'itinérance sécurisés avec ce réseau d'accès, le fait que le réseau d'accès utilisé par le terminal pour s'enregistrer auprès du cœur de réseau est un réseau d'accès visité (situation de roaming international), ou encore le fait que le réseau d'accès utilisé par le terminal se situe ou non dans le réseau nominal (réseau home) du serveur établissant la recommandation, etc.
Il convient de noter qu'au sens de l'invention, un réseau d'accès peut comprendre un ou plusieurs (sous-)réseaux d'accès.
Ce conditionnement est exprimé, conformément à l'invention, sous la forme d'une recommandation d'établir ou non le tunnel sécurisé, émise par un serveur du cœur de réseau IP multimédia lors de l'enregistrement du terminal (c'est-à-dire finalement, lorsque l'établissement du tunnel sécurisé est requis par le terminal).
La recommandation est élaborée par le serveur, en fonction du réseau d'accès identifié, en prenant en compte préférentiellement un niveau de sécurisation des données associé (ou attribué) par le cœur de réseau IP multimédia au réseau d'accès utilisé par le terminal.
Ce niveau de sécurisation peut dépendre de plusieurs facteurs, comme par exemple du type du réseau d'accès (ex. accès 3GPP, accès WiFi (Wireless Fidelity), etc.), de l'existence de procédures de sécurisation fortes mises en œuvre sur ce réseau, de la mise en place d'accords d'itinérance sécurisés par le cœur de réseau avec ce réseau d'accès, etc. Il reflète la confiance qu'a le cœur de réseau IP multimédia (i.e. l'opérateur du cœur de réseau IP multimédia) dans la sécurisation des échanges de données assuré par le réseau d'accès. Ainsi, un cœur de réseau IP multimédia peut associer à un réseau d'accès un niveau de sécurisation faible en dépit des algorithmes de chiffrement mis en œuvre par ce réseau d'accès, par exemple parce que ce réseau d'accès est associé à une zone géographique sensible, etc.
Cette recommandation permet ainsi au serveur d'indiquer un degré de nécessité (ou d'obligation) d'établir le tunnel sécurisé normalement prévu par le cœur de réseau entre le terminal et l'entité de raccordement, compte tenu du niveau de sécurisation garanti par le réseau d'accès selon le cœur de réseau IP multimédia.
Elle a bien entendu vocation à être transmise au terminal et/ou à l'entité de raccordement pour être exécutée lors de l'enregistrement du terminal.
La recommandation émise par le serveur comprend préférentiellement l'une des indications suivantes :
— une indication de ne pas établir le tunnel sécurisé entre le terminal et l'entité de raccordement, par exemple parce que le cœur de réseau IP considère que le réseau d'accès utilisé par le terminal comprend des procédures de chiffrement suffisamment fortes et fiables pour garantir la protection et l'intégrité des données transmises ou reçues par le terminal ;
— une indication de libre choix quant à l'établissement du tunnel sécurisé entre le terminal et l'entité de raccordement ; — une indication d'établir le tunnel sécurisé entre le terminal et l'entité de raccordement, par exemple parce que le réseau d'accès utilisé par le terminal n'est pas considéré comme suffisamment sécurisé au vu de certains critères prédéterminés (ex. absence de chiffrement des données, absence de contrôle de l'intégrité des données, etc.).
Ainsi, par exemple, si la requête d'enregistrement du terminal est reçue via un réseau d'accès 3GPP (autrement dit, via un réseau d'accès radio sécurisé de par la définition de la norme 3GPP), qui est par ailleurs identifié comme étant le réseau d'accès nominal du terminal ou un réseau d'accès avec lequel un accord d'itinérance fort est conclu, le serveur peut préconiser, dans sa recommandation, de ne pas établir le tunnel sécurisé entre le terminal et l'entité de raccordement, ou en variante, laisser libre choix dans cette recommandation au terminal d'établir ou non ce tunnel sécurisé.
Au contraire, si le terminal tente de s'enregistrer via un réseau d'accès fixe depuis un hot spot WiFi public non sécurisé, le serveur peut alors préconiser dans sa recommandation d'établir le tunnel sécurisé entre le terminal et l'entité de raccordement.
La recommandation du serveur peut être élaborée par le serveur en comparant des caractéristiques et/ou le type du réseau d'accès utilisé par le terminal par rapport à des critères de sécurisation prédéterminés, pour déterminer si le niveau de sécurisation assuré par le réseau d'accès est suffisant pour relâcher la contrainte d'établissement du tunnel sécurisé entre le terminal et l'entité de raccordement.
Dans une variante de réalisation privilégiée et relativement simple, la recommandation du serveur est élaborée en consultant une table ou une base de données préétablie, dans laquelle on associe à différents réseaux d'accès, une recommandation sur la nécessité (ou l'obligation) ou non d'établir le tunnel de sécurité entre le terminal et l'entité de raccordement.
Cette table peut être renseignée par l'opérateur du cœur de réseau IP multimédia en fonction du niveau de sécurisation des échanges qu'il associe aux différents réseaux d'accès : ce niveau de sécurisation peut être établi par l'opérateur du cœur de réseau, comme mentionné précédemment, en tenant compte notamment de la connaissance a priori des procédures de sécurité (chiffrement, contrôle de l'intégrité, etc.) mises en œuvre sur ces différents réseaux d'accès (ex. en fonction du type de réseau d'accès et/ou de l'opérateur de ces réseaux, de la définition des standards respectés par ces réseaux d'accès), de l'existence ou non d'accords d'itinérance « forts » (fiables) avec les réseaux d'accès, voire de l'absence d'informations suffisantes sur un réseau d'accès, etc.
La recommandation émise par le serveur du cœur de réseau IP multimédia offre ainsi la possibilité de s'affranchir de l'établissement d'un lien (tunnel) sécurisé entre le terminal et l'entité de raccordement quand une protection forte des données et de leur intégrité est déjà assurée par le réseau d'accès utilisé par le terminal.
On économise par ce biais des ressources à la fois au niveau du terminal (la durée de vie de la batterie est préservée) et au niveau de l'entité de raccordement. En variante, on peut ne prévoir que deux types de recommandation possibles émis par le serveur, à savoir, une indication de ne pas établir le tunnel sécurisé ou une indication d'établir le tunnel sécurisé, de sorte à être plus directif. Cette variante permet d'économiser davantage de ressources au niveau du terminal et de l'entité de raccordement.
L'invention a donc une application privilégiée mais non limitative lorsque le cœur de réseau IP multimédia implémente une architecture IMS, dans lequel l'établissement d'un tunnel sécurisé lors de l'enregistrement d'un terminal est prévu conformément au standard 3GPP. De manière plus générale, elle s'applique à tout cœur de réseau IP multimédia prévoyant l'établissement d'un tunnel sécurisé entre le terminal et le cœur de réseau à l'accès (lors de l'enregistrement du terminal auprès du cœur de réseau).
Dans un contexte IMS, le serveur du cœur de réseau IP multimédia émettant la recommandation peut être un serveur S-CSCF, et le message dans lequel est insérée la recommandation est alors émis par le serveur S-CSCF à destination du terminal via un serveur P- CSCF raccordant le terminal au cœur de réseau IP multimédia.
II convient de noter que la recommandation élaborée par le serveur S-CSCF est préférentiellement insérée dans un message de réponse intermédiaire à la requête d'enregistrement du terminal tel un message SIP 401 Unauthorized, émis par le serveur S-CSCF à destination du terminal, conformément au protocole SIP.
Le serveur P-CSCF peut alors, propager cette recommandation au terminal pour inhiber ou au contraire déclencher l'établissement du tunnel sécurisé entre le terminal et le serveur P-CSCF.
Un même serveur S-CSCF pouvant être en relation avec plusieurs serveurs P-CSCF, cette variante présente l'avantage de limiter la complexité liée à la mise en œuvre de l'invention et donc d'optimiser l'exploitation du cœur de réseau (notamment, une seule table préétablie a besoin d'être mémorisée au niveau du serveur S-CSCF pour émettre des recommandations relatives à plusieurs entités de raccordement).
Par ailleurs, cette variante offre la possibilité de prendre en compte facilement, pour élaborer la recommandation (ou la pondérer), des informations contenues dans le profil de l'utilisateur du terminal. Ainsi par exemple, on peut envisager d'associer dans le profil de l'utilisateur du terminal, une indication selon laquelle pour cet utilisateur, un tunnel sécurisé doit toujours être établi, indépendamment du niveau de sécurisation associé au réseau d'accès utilisé par le terminal pour s'enregistrer.
En variante, le serveur du cœur de réseau IP multimédia émettant la recommandation peut être un serveur P-CSCF, et le message dans lequel est insérée la recommandation est alors émis vers le terminal.
La recommandation élaborée par le serveur P-CSCF est préférentiellement insérée dans un message de réponse intermédiaire à la requête d'enregistrement du terminal tel un message SIP 401 Unauthorized émis par le serveur S-CSCF à destination du terminal et qui transite par le serveur P-CSCF, conformément au protocole SIP.
Autrement dit, le serveur émettant la recommandation peut être l'entité de raccordement elle-même du terminal au cœur de réseau IP multimédia. Cette variante permet d'avoir une gestion plus locale de l'établissement du tunnel sécurisé et de prendre en compte plus facilement des spécificités locales de l'accès au cœur de réseau (ex. présence de certains réseaux d'accès (ex. WiFi) dans une localisation particulière).
Dans une autre variante encore, une recommandation est élaborée conformément à l'invention à la fois par un serveur S-CSCF et par un serveur P-CSCF du cœur de réseau IP multimédia. Dans cette variante de réalisation, si les recommandations élaborées respectivement par le serveur S-CSCF et par le serveur P-CSCF sont différentes, seule la recommandation émise par le serveur P-CSCF est prise en compte et transmise en définitive au terminal. Autrement dit, la recommandation émise par le serveur P-CSCF vient écraser la recommandation émise par le serveur S-CSCF dans le message de réponse intermédiaire SIP 401 Unauthorized.
De manière plus générale, le serveur selon l'invention peut être intégré dans n'importe quelle entité du cœur de réseau apte à recevoir des requêtes d'enregistrement des terminaux contenant une demande d'établissement d'un tunnel sécurisé entre le terminal et l'entité de raccordement de ce terminal au cœur de réseau.
Dans un mode particulier de réalisation de l'invention, la recommandation est élaborée en fonction également d'au moins un paramètre reçu avec la requête d'enregistrement.
Ce paramètre peut être notamment contenu dans la requête d'enregistrement ou véhiculé dans la signalisation associée à cette requête d'enregistrement.
Ce mode de réalisation permet, pour un même réseau d'accès ou pour un même type de réseau d'accès, de pondérer le conditionnement en fonction du réseau d'accès mis en œuvre par le serveur, par l'intermédiaire du paramètre contenu dans la requête d'enregistrement.
Ce paramètre peut être notamment une adresse IP de transport de la requête d'enregistrement, c'est-à-dire l'adresse source de la requête d'enregistrement du terminal telle que reçue par le serveur. De façon connue de l'homme du métier, cette adresse source peut, selon les configurations de réseau envisagées, correspondre à l'adresse de contact ou à l'adresse IP du terminal cherchant à s'enregistrer (ex. pour un réseau d'accès mobile), ou à l'adresse IP d'une entité intermédiaire entre le terminal et le serveur (ex. passerelle domestique).
Ainsi, à titre d'exemple, pour un même réseau d'accès, on pourra avantageusement décider d'émettre une recommandation ferme de ne pas établir de tunnel sécurisé pour un certain intervalle d'adresses IP tandis qu'un libre choix sera laissé pour un autre intervalle d'adresses IP ou une sélection d'adresses IP.
En variante, ce paramètre peut être un identifiant associé à l'utilisateur du terminal, tel qu'un identifiant IMSI (International Mobile Subscriber Identity) ou MSISDN (Mobile Station Integrated Services Digital Network). De cette sorte, par exemple, pour un même réseau d'accès, on peut décider d'émettre de façon générale une recommandation de ne pas établir de tunnel sécurisé, sauf pour certains utilisateurs identifiés au préalable (par exemple en insérant dans le profil de ces utilisateurs un indicateur approprié), pour lesquels une recommandation d'établir un tunnel sécurisé sera toujours émise au contraire.
Plus généralement, la prise en compte d'un paramètre tel qu'un identifiant associé à l'utilisateur du terminal permet de pondérer la recommandation élaborée par rapport au réseau d'accès utilisé par le terminal, en fonction d'informations associées à cet identifiant et présentes notamment dans le profil de l'utilisateur. Ces informations comprennent par exemple les services auxquels a souscrit l'utilisateur, ses préférences, son appartenance à une catégorie d'abonnés sensibles pour lesquels un lien sécurisé doit toujours être mis en œuvre, etc.
Dans un mode particulier de réalisation de l'invention, le message émis est conforme au protocole SIP, et la recommandation du serveur est insérée dans un champ « Security Server » de ce message.
Ce mode de réalisation permet de s'interfacer aisément avec le standard SIP existant, moyennant l'ajout d'un paramètre idoine dans le champ « Security Server » défini par le standard 3GPP dans l'annexe H du document de spécification TS 33.203, pour informer le terminal ou l'entité de raccordement que la mise en œuvre d'un tunnel sécurisé doit (ou peut) ou non avoir lieu.
Dans un mode particulier de réalisation, le message émis par le serveur contient en outre des informations permettant l'établissement du tunnel sécurisé entre le terminal et l'entité de raccordement.
Ce mode de réalisation est compatible avec les terminaux qui ne sont pas capables d'interpréter et/ou d'exécuter la recommandation émise par le serveur. Un tel terminal pourra ainsi, quel que soit l'avis émis par le serveur et la sécurisation assurée par le réseau d'accès, établir un lien sécurisé à partir des informations contenues dans le message, de sorte à garantir la protection et l'intégrité des données échangées avec le cœur de réseau.
Par ailleurs, ces informations peuvent également être utilisées lorsque la recommandation émise par le serveur laisse un libre choix quant à l'établissement ou non du tunnel sécurisé.
Il convient de noter que l'efficacité de l'invention à réduire la complexité et le surcoût en matière de ressources résultant de l'existence d'un double chiffrement des données repose d'une part, sur le serveur qui émet la recommandation quant à l'établissement ou non du tunnel sécurisé en fonction du réseau d'accès utilisé par le terminal, et d'autre part, sur le terminal lu i- même, dès lors que celui-ci est apte à exécuter la recommandation émise par le serveur lors de son enregistrement auprès du cœur de réseau.
Ainsi, selon un autre aspect, l'invention vise également un procédé d'enregistrement d'un terminal auprès d'un cœur de réseau IP, ce procédé comprenant : — une étape d'émission, par le terminal, d'une requête d'enregistrement auprès du cœur de réseau, via un réseau d'accès, ladite requête d'enregistrement proposant une méthode d'authentification prévoyant l'établissement d'un tunnel sécurisé entre le terminal et une entité de raccordement de ce terminal au cœur de réseau ;
— une étape de réception, par le terminal, en provenance du cœur de réseau, d'une recommandation quant à l'établissement ou non du tunnel sécurisé entre le terminal et l'entité de raccordement pour ladite méthode d'authentification, cette recommandation provenant d'un message émis par un serveur du cœur de réseau conformément à un procédé d'émission selon l'invention, exécuté suite à la réception de la requête d'enregistrement du terminal ; et — une étape d'interprétation de cette recommandation par le terminal.
Corrélativement, l'invention vise aussi un terminal comprenant :
— des moyens d'émission d'une requête d'enregistrement auprès d'un cœur de réseau IP multimédia via un réseau d'accès, ladite requête d'enregistrement proposant une méthode d'authentification prévoyant l'établissement d'un tunnel sécurisé entre le terminal et une entité de raccordement de ce terminal au cœur de réseau ;
— des moyens de réception, en provenance du cœur de réseau, d'une recommandation quant à l'établissement ou non du tunnel sécurisé entre le terminal et l'entité de raccordement pour ladite méthode d'authentification, cette recommandation provenant d'un message émis par un serveur du cœur de réseau conforme à l'invention, suite à la réception de la requête d'enregistrement ; et
— des moyens d'interprétation de cette recommandation.
Le procédé d'enregistrement et le terminal bénéficient des mêmes avantages que ceux cités précédemment pour le procédé d'émission d'un message et le serveur.
L'invention vise aussi une entité de raccordement d'un terminal à un cœur de réseau IP multimédia, cette entité de raccordement comprenant :
— des moyens de réception d'une requête d'enregistrement du terminal auprès du cœur de réseau, via un réseau d'accès, ladite requête d'enregistrement proposant une méthode d'authentification prévoyant l'établissement d'un tunnel sécurisé entre ledit terminal et ladite entité de raccordement ;
— des moyens de transmission de ladite requête d'enregistrement à un serveur conforme à l'invention ;
— des moyens de réception, en provenance du serveur, d'un message contenant une recommandation quant à l'établissement ou non du tunnel sécurisé entre le terminal et l'entité de raccordement pour ladite méthode d'authentification ; et
— des moyens de transmission de cette recommandation au terminal.
Corrélativement, l'invention vise aussi un procédé de transmission destiné à être mis en œuvre par une entité de raccordement d'un terminal à un cœur de réseau IP multimédia, ce procédé de transmission comprenant : — une étape de réception d'une requête d'enregistrement du terminal auprès du cœur de réseau, via un réseau d'accès, ladite requête d'enregistrement proposant une méthode d'authentification prévoyant l'établissement d'un tunnel sécurisé entre ledit terminal et ladite entité de raccordement ;
— une étape de transmission de cette requête d'enregistrement à un serveur du cœur de réseau ;
— une étape de réception, en provenance du serveur, d'un message contenant une recommandation quant à l'établissement ou non du tunnel sécurisé entre le terminal et l'entité de raccordement pour ladite méthode d'authentification, le message résultant de l'exécution par le serveur d'un procédé d'émission d'un message conforme à l'invention ; et
— une étape de transmission de cette recommandation au terminal.
L'entité de raccordement relaie ainsi la recommandation émise par le serveur du cœur de réseau IP multimédia jusqu'au terminal afin que celui-ci applique cette recommandation. Il convient de noter qu'aucune limitation n'est attachée à la façon dont la recommandation est transmise à proprement parler au terminal, i.e. l'entité de raccordement peut juste inclure en l'état la recommandation dans un message envoyé au terminal (ex. dans un paramètre du champ Security Server d'un message SIP), ou au contraire modifier la forme à proprement parler de cette recommandation, par exemple en n'envoyant pas les informations nécessaires à l'établissement du tunnel si la recommandation émise par le serveur est de ne pas établir le tunnel entre le terminal et l'entité de raccordement.
Dans un mode particulier de réalisation, les différentes étapes du procédé d'émission d'un message et/ou du procédé d'enregistrement et/ou du procédé de transmission sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un serveur ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé d'émission d'un message tel que décrit ci-dessus.
L'invention vise également un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un terminal ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé d'enregistrement tel que décrit ci-dessus.
L'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans une entité de raccordement ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de transmission tel que décrit ci-dessus.
Ces programmes peuvent utiliser n'importe quel langage de programmation, et être sous la forme de codes source, codes objet, ou de codes intermédiaires entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
L'invention vise également un système de communication comprenant :
— un serveur d'un cœur de réseau IP multimédia conforme à l'invention ;
— un terminal selon l'invention, apte à s'enregistrer auprès du cœur de réseau multimédia en envoyant une requête d'enregistrement au cœur de réseau via un réseau d'accès,
— une entité de raccordement du terminal au cœur de réseau IP multimédia ;
le terminal étant apte à exécuter une recommandation élaborée par le serveur quant à l'établissement ou non d'un tunnel sécurisé entre le terminal et l'entité de raccordement du terminal au cœur de réseau.
Ainsi, le système de communication selon l'invention permet de relâcher la contrainte d'établissement du tunnel sécurisé entre le terminal et l'entité de raccordement lorsqu'un niveau de sécurisation des échanges suffisant est associé au réseau d'accès par le cœur de réseau IP multimédia. On économise par ce biais les ressources du terminal et de l'entité de raccordement.
On peut également envisager, dans d'autres modes de réalisation, que le procédé d'émission d'un message, le procédé d'enregistrement, le procédé de transmission, le serveur, le terminal, l'entité de raccordement et le système de communication selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins et annexes qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif : — la figure 1 représente, de façon schématique, un système de communication, un serveur, une entité de raccordement et un terminal conformes à l'invention, dans un premier mode de réalisation ;
— les figures 2A, 2B et 2C représentent, de façon schématique, les architectures matérielles respectives du terminal, du serveur et de l'entité de raccordement de la figure 1, dans le premier mode de réalisation ;
— la figure 3 représente, sous forme d'ordinogrammes, les principales étapes d'un procédé d'enregistrement, d'un procédé de transmission et d'un procédé d'émission d'un message telles qu'elles sont mises en œuvre respectivement par le terminal, l'entité de raccordement et le serveur de la figure 1 dans le premier mode de réalisation ;
— la figure 4 illustre une table associant à différents réseaux d'accès, une recommandation quant à l'établissement d'un lien sécurisé, et utilisée par le serveur de la figure 1 pour élaborer sa recommandation dans le premier mode de réalisation ;
— la figure 5 représente, de façon schématique, un système de communication, un serveur et un terminal conformes à l'invention, dans un second mode de réalisation ;
— la figure 6 représente schématiquement l'architecture matérielle du serveur de la figure 5 ;
— la figure 7 représente, sous forme d'ordinogrammes, les principales étapes d'un procédé d'enregistrement et d'un procédé d'émission d'un message telles qu'elles sont mises en œuvre respectivement par le terminal et le serveur de la figure 5 dans le second mode de réalisation ; — l'annexe 1 donne des exemples de requêtes d'enregistrement du terminal de la figure 1 et de messages contenant une recommandation émise par le serveur de la figure 1, dans le premier mode de réalisation ; et
— l'annexe 2 donne des exemples d'une requête d'enregistrement du terminal de la figure 5 et d'un message contenant une recommandation émise par le serveur de la figure 5, dans le second mode de réalisation.
Description détaillée de l'invention
La figure 1 représente, dans son environnement, un système 1 de communication conforme à l'invention, dans un premier mode de réalisation.
Le système 1 de communication comprend un terminal 2 conforme à l'invention, apte à s'enregistrer auprès d'un cœur CN de réseau IP multimédia via un réseau d'accès AN.
Aucune limitation n'est attachée ici à la nature du terminal 2. Il peut s'agir aussi bien d'un terminal mobile, tel un téléphone intelligent (ou smartphone), un ordinateur portable, ou un assistant numérique personnel (ou PDA pour Personal Digital Assistant), que d'un terminal fixe.
Dans le premier mode de réalisation décrit ici, le terminal 2 dispose de l'architecture matérielle d'un ordinateur, telle qu'illustrée schématiquement à la figure 2A.
Il comporte un processeur 2A, une mémoire vive 2B, une mémoire morte 2C, une mémoire flash non volatile 2D, ainsi que des moyens de communication 2E mettant en œuvre notamment le protocole SIP et lui permettant de communiquer via le réseau d'accès AN. Les moyens de communication 2E permettent au terminal 2 de communiquer notamment avec les entités du cœur de réseau CN.
La mémoire morte 2C du terminal 2 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 2A et sur lequel est enregistré un programme d'ordinateur conforme à l'invention, comportant des instructions pour l'exécution des étapes d'un procédé d'enregistrement auprès du cœur de réseau CN conforme à l'invention, décrites ultérieurement en référence à la figure 3.
Il convient de noter qu'aucune limitation n'est attachée au réseau d'accès AN utilisé par le terminal 2 pour se connecter et s'enregistrer auprès du cœur de réseau CN, dès lors que ce réseau d'accès est connu du cœur de réseau CN. Ce réseau d'accès peut ainsi être, par exemple, un réseau d'accès 3GPP, un réseau d'accès xDSL, un réseau d'accès EPC, etc. Il peut être géré par le même opérateur que le cœur de réseau CN ou par un opérateur distinct.
Le cœur de réseau CN repose ici sur une architecture IMS, implémentant le protocole SIP, telle que décrite dans le document de spécification TS23.228 du standard 3GPP, intitulé « IP Multimedia Subsystem ; Stage 2 », Release 9, septembre 2010, disponible sur le site www.3qpp.org.
De façon connue, un cœur de réseau implémentant une architecture IMS comprend plusieurs entités fonctionnelles dont notamment, une entité CSCF (Call Session Control Function) composée de plusieurs serveurs, parmi lesquels :
— un serveur S-CSCF (Serving-Call Session Control Function), en charge en particulier de l'enregistrement des terminaux sur le cœur de réseau ; et
— un serveur P-CSCF (Proxy Call Session Control Function), jouant le rôle d'entité de raccordement des terminaux avec le cœur de réseau.
Ainsi, dans l'exemple illustré à la figure 1, le cœur de réseau CN comprend un serveur
P-CSCF 3, point d'entrée du terminal 2 sur le cœur de réseau CN, et un serveur S-CSCF 4, chargé de l'enregistrement du terminal 2 auprès du cœur de réseau CN. Conformément au fonctionnement du cœur de réseau IMS CN, les requêtes d'enregistrement auprès du cœur de réseau CN émises par le terminal 2 transitent par le serveur P-CSCF 3 avant d'être acheminées pour traitement vers le serveur S-CSCF 4.
Comme mentionné précédemment, le standard 3GPP prévoit (requiert), selon le type de terminal et le type de carte SIM (Subscriber Identity Module) équipant le terminal (présence d'une carte USIM (Universal Subscriber Identity Module) ou ISIM (International Subscriber Identity Module)), lors de l'enregistrement d'un terminal auprès d'un cœur de réseau IMS (et donc auprès du cœur de réseau CN), l'établissement d'un tunnel sécurisé entre le terminal et l'entité de raccordement de ce terminal au cœur de réseau, autrement dit, entre le terminal et le serveur P- CSCF associé à ce terminal. Par tunnel sécurisé établi entre deux entités (ex. un terminal et un serveur P-CSCF), on entend, de manière classique, un lien sécurisé établi entre les deux entités assurant, au moyen de clés adéquates, le chiffrement et/ou l'intégrité des données échangées entre ces deux entités.
L'invention propose avantageusement, afin de préserver les ressources du terminal et du serveur P-CSCF, de conditionner l'établissement de ce tunnel sécurisé en fonction au moins du réseau d'accès emprunté par le terminal.
Il convient de noter que l'invention ne se limite pas à une architecture de type IMS. Elle peut en effet s'appliquer à d'autres architectures de cœurs de réseau IP Multimédia prévoyant l'établissement d'un tunnel sécurisé lors de l'enregistrement d'un terminal, telles que notamment des architectures propriétaires.
Dans le premier mode de réalisation décrit ici, le conditionnement de l'établissement du tunnel sécurisé entre le terminal 2 et le serveur P-CSCF 3 est réalisé via une recommandation élaborée par le serveur S-CSCF 4. Le serveur S-CSCF 4 du cœur de réseau CN intègre ainsi d'une part les fonctionnalités d'un serveur S-CSCF tel que défini par le standard 3GPP, et d'autre part les caractéristiques d'un serveur du système 1 de communication conforme à l'invention.
Le serveur S-CSCF 4 dispose ici de l'architecture matérielle d'un ordinateur, telle qu'illustrée schématiquement à la figure 2B.
Il comporte notamment un processeur 4A, une mémoire vive 4B, une mémoire morte 4C, une mémoire flash non volatile 4D ainsi que des moyens de communication 4E mettant en œuvre notamment le protocole SIP. Ces moyens de communication lui permettent de communiquer avec les entités du cœur de réseau CN et avec le terminal 2.
La mémoire morte 4C du serveur S-CSCF 4 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 4A et sur lequel est enregistré un programme d'ordinateur conforme à l'invention, comportant des instructions pour l'exécution des étapes d'un procédé d'émission d'un message conforme à l'invention décrites ultérieurement en référence à la figure 3.
Par ailleurs, dans le premier mode de réalisation, la recommandation élaborée par le serveur S-CSCF 4 quant à l'établissement ou non du tunnel sécurisé entre le terminal 2 et le serveur P-CSCF 3 est relayée par le serveur P-CSCF 3 jusqu'au terminal 2. Ainsi, le serveur P-CSCF 3 intègre non seulement les fonctionnalités d'un serveur P-CSCF tel que défini par le standard 3GPP, mais également les caractéristiques d'une entité de raccordement conforme à l'invention.
Le serveur P-CSCF 3 dispose ici de l'architecture matérielle d'un ordinateur, telle qu'illustrée schématiquement à la figure 2C.
Il comporte un processeur 3A, une mémoire vive 3B, une mémoire morte 3C, une mémoire flash non volatile 3D, ainsi que des moyens de communication 3E mettant en œuvre notamment le protocole SIP. Ces moyens de communication 3E lui permettent de communiquer notamment avec le terminal 2 ainsi qu'avec les autres entités du cœur de réseau CN telles que le serveur S-CSCF 4. La mémoire morte 3C du serveur P-CSCF 3 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 3A et sur lequel est enregistré un programme d'ordinateur conforme à l'invention, comportant des instructions pour l'exécution des étapes d'un procédé de transmission conforme à l'invention, décrites maintenant en référence à la figure 3.
Nous allons maintenant décrire, en référence à la figure 3, les principales étapes d'un procédé d'enregistrement, d'un procédé de transmission et d'un procédé d'émission d'un message mises en œuvre respectivement par le terminal 2, par le serveur P-CSCF 3 et par le serveur S-CSCF 4, dans le premier mode de réalisation.
Par souci de simplification, on se limite dans ce premier mode de réalisation, à une recommandation élaborée par le serveur S-CSCF 4 uniquement en fonction du réseau d'accès utilisé par le terminal 2 pour s'enregistrer auprès du cœur de réseau CN.
Cette hypothèse n'est toutefois pas limitative et d'autres paramètres peuvent être pris en compte, en plus du réseau d'accès utilisé par le terminal 2, pour élaborer une recommandation. Ces paramètres permettent avantageusement de pondérer la recommandation établie en fonction du réseau d'accès du terminal 2, comme mentionné ultérieurement dans la description.
On suppose que le terminal 2 souhaite s'enregistrer auprès du cœur de réseau CN, via le réseau d'accès AN, pour accéder par exemple à des services multimédia gérés par le cœur de réseau CN.
A cette fin, le terminal 2 émet, via ses moyens de communications 2E, une requête d'enregistrement REGI à destination du cœur de réseau CN (étape E10). Dans le premier mode de réalisation décrit ici, cette requête d'enregistrement REGI est une requête SIP REGISTER.
Un exemple d'une telle requête est donné en annexe 1 (cf. exemple Ex. 1). Elle comprend notamment, de façon connue, un identifiant de l'utilisateur du terminal 2 dans les champs « From » et « To », ainsi qu'une information relative au réseau d'accès AN utilisé par le terminal 2 pour s'enregistrer auprès du cœur de réseau CN. Cette information se trouve dans le champ « P-Access-Network-Info » de la requête REG. Ainsi, dans l'exemple de l'annexe 1, AN est un réseau d'accès de type 3GPP-UTRAN-TDD.
La requête REGI émise par le terminal 2 contient également des informations relatives à l'établissement d'un tunnel sécurisé avec le serveur P-CSCF 3 du cœur de réseau CN, conformément au standard 3GPP. Ces informations sont contenues dans le champ « Security- Client » de la requête d'enregistrement. Ainsi, le tunnel sécurisé proposé par le terminal sera de type IPsec pour une authentification IMS AKA, et de type TLS pour une authentification SIP digest avec TLS. Par exemple, dans l'exemple Ex. 1 de l'annexe 1, l'information « ipsec-3gpp » indique qu'il s'agit du protocole IPsec. Lesdites informations peuvent comprendre également les algorithmes de chiffrement et de contrôle d'intégrité envisagés (dans l'exemple Ex. 1, il s'agit des algorithmes connus « hmac-shal-96 » et « des-ede3-cbc »), les ports sur lesquels le tunnel doit être monté, etc. La requête d'enregistrement REGI est reçue par le serveur P-CSCF 3 raccordant le terminal 2 au cœur de réseau CN (étape F10).
Sur réception de cette requête, le serveur P-CSCF 3 identifie quel réseau d'accès AN est utilisé par le terminal 2 pour s'enregistrer auprès du cœur de réseau CN (étape F20).
II convient de noter que l'information de réseau d'accès, incluse par le terminal 2 dans sa requête d'enregistrement REGI, n'est pas nécessairement fiable, de sorte que le serveur P-CSCF 3 détermine ici par ses propres moyens quel réseau d'accès AN emprunte le terminal 2.
Il utilise à cette fin des techniques connues de l'homme du métier.
L'une de ces techniques consiste à établir lors d'une phase préliminaire, et à maintenir à jour, au niveau du serveur P-CSCF 3, une table de correspondance dans laquelle on associe à une plage d'adresses IP, un réseau d'accès. Ces adresses IP correspondent à des adresses IP de transport susceptibles d'être utilisées pour transporter les requêtes des terminaux cherchant à se connecter au cœur de réseau CN (et donc à s'enregistrer auprès du cœur de réseau CN). Il peut s'agir, selon les configurations de réseau envisagées, des adresses IP ou adresses de contact des terminaux cherchant à se connecter, ou des adresses IP d'entités intermédiaires entre ces terminaux et le serveur P-CSCF 3.
Une telle table peut être aisément établie par l'opérateur du cœur de réseau CN, pour chaque réseau d'accès connu de l'opérateur (à chaque nouvelle installation d'un réseau d'accès par exemple).
Ainsi, dans le premier mode de réalisation décrit ici, le serveur P-CSCF 3 détermine dans un premier temps, selon des moyens connus de l'homme du métier, l'adresse IP de transport de la requête d'enregistrement REGI qu'il a reçue (c'est-à-dire l'adresse IP source de la requête REGI telle que reçue par le serveur P-CSCF 3).
Puis, il compare cette adresse IP de transport aux plages d'adresses IP renseignées dans la table de correspondance. Il en déduit ainsi le réseau d'accès AN utilisé par le terminal 2 pour s'enregistrer (étape F20).
Le serveur P-CSCF 3 remplace si nécessaire, l'information contenue dans le champ « P- Access-Network-Info » de la requête d'enregistrement REGI, par le réseau AN obtenu à l'aide de l'adresse IP de transport de la requête REGI (étape F30). L'information contenue dans le champ P- Access-Network-Info, suite à cette modification, est une information réseau certifiée par le serveur P-CSCF 3.
Le serveur P-CSCF 3 modifie également certains champs de la requête, de façon connue en soi, conformément au standard 3GPP. Ainsi, par exemple, il supprime de la requête le champ « Security-Client ».
La requête d'enregistrement du terminal modifiée par le serveur P-CSCF 3 est alors transmise à l'aide de ses moyens de communications 3E au serveur S-CSCF 4, sous la forme d'une requête REG2 (étape F40). La requête REG2 est, en dépit des modifications apportées à la requête REGI reçue du terminal 2, une requête d'enregistrement du terminal 2 au sens de l'invention. En Annexe 1, un exemple de requête REG2 dérivée de la requête REGI donnée dans l'exemple Ex. 1 est fourni dans l'exemple Ex. 2.
Sur réception de la requête REG2 d'enregistrement du terminal 2 (étape G10), le serveur S-CSCF 4 identifie le réseau d'accès AN utilisé par le terminal 2 pour s'enregistrer, en consultant le champ « P-Access-Network-Info » de la requête, positionné par le serveur P-CSCF 3 (étape G20).
Puis il élabore, en fonction du réseau d'accès ainsi identifié, une recommandation RECO quant à l'établissement ou non du tunnel sécurisé entre le terminal 2 et le serveur P-CSCF 3 (étape G30). Cette recommandation traduit le caractère opportun (c'est-à-dire utile ou obligatoire) de l'établissement du tunnel sécurisé entre le terminal 2 et le serveur P-CSCF 3 de sorte à garantir la protection et l'intégrité des données échangées entre le terminal 2 et le cœur de réseau CN.
Cette recommandation est élaborée ici en prenant en compte un niveau de sécurisation des données associé par le cœur de réseau IP multimédia au réseau d'accès utilisé par le terminal.
A cette fin, dans le premier mode de réalisation décrit ici, le serveur S-CSCF 4 utilise une table (ou base de données) T préétablie, dans laquelle on associe à différents réseaux d'accès, une recommandation sur la nécessité ou non d'établir le tunnel de sécurité entre le terminal et l'entité de raccordement. La table T est par exemple stockée dans la mémoire non volatile 4D du serveur S-CSCF 4.
Cette table T est renseignée ici par l'opérateur du cœur de réseau CN, en fonction du niveau de sécurisation des échanges (ex. insuffisant ou faible versus suffisant ou fort) qu'il associe aux différents réseaux d'accès. Ainsi, si le niveau de sécurisation d'un réseau d'accès est considéré comme fort, une recommandation de ne pas établir de tunnel sécurisé est associée dans la table T à ce réseau d'accès. Inversement, si le niveau de sécurisation d'un réseau d'accès est considéré comme faible, une recommandation d'établir le tunnel sécurisé est associée dans la table T à ce réseau d'accès.
Le niveau de sécurisation d'un réseau d'accès peut être établi par l'opérateur en tenant compte notamment de la connaissance a priori des procédures de sécurité (chiffrement, contrôle de l'intégrité, etc.) mises en œuvre sur ces différents réseaux d'accès (ex. en fonction du type de réseau d'accès et/ou de l'opérateur de ces réseaux, de la définition des standards respectés par ces réseaux d'accès), de l'existence ou non d'accords d'itinérance « forts » (fiables) avec les réseaux d'accès, voire de l'absence d'informations suffisantes sur les procédures de sécurisation mises en œuvre par un réseau d'accès, etc.
Un exemple d'une telle table T est illustré à la figure 4. Dans cet exemple, on associe à un réseau d'accès 3GPP-UTRAN-TDD et à un réseau d'accès 3GPP-UTRAN-FDD, une recommandation de ne pas établir de tunnel sécurisé entre le terminal 2 et le serveur P-CSCF 3 (recommandation « Not required »), tandis qu'on associe à un réseau d'accès WiFi Public, une recommandation d'établir le tunnel sécurisé (recommandation « Required »). Autrement dit, on associe implicitement dans cette table un niveau de sécurisation fort aux réseaux d'accès 3GPP- UTRAN-TDD et 3GPP-UTRAN-FDD, et un niveau de sécurisation faible au réseau d'accès WiFi Public.
En variante, on peut envisager un autre type de recommandation, laissant libre choix au terminal 2 et/ou au serveur P-CSCF 3 d'établir ou non le tunnel sécurisé préconisé par le standard 3GPP.
Dans l'exemple illustré en Annexe 1, le réseau d'accès AN utilisé par le terminal 2 est un réseau d'accès de type 3GPP-UTRAN-TDD. Il est associé à une recommandation RECO de ne pas établir le tunnel sécurisé entre le terminal 2 et le serveur P-CSCF 3.
Le serveur S-CSCF 4 insère la recommandation RECO obtenue en consultant la table T à partir du réseau d'accès AN dans un message Ml à destination du terminal 2 (étape G40). Dans l'exemple décrit ici, le message Ml est un message SIP 401 Unauthorized de réponse intermédiaire à la requête d'enregistrement du terminal 2, qui transite par le serveur P-CSCF 3, conformément au protocole SIP.
Un exemple d'un tel message Ml contenant la recommandation RECO du serveur S-
CSCF 4 est donné en Annexe 1 (cf. exemple Ex. 3). La recommandation est insérée dans cet exemple dans le header (champ) « Security-Server » (cf. l'Annexe H de la spécification TS 33.203) du message SIP Ml, à l'aide d'un paramètre « tunnel » positionné à la valeur « not_required ».
Bien entendu, d'autres façons d'insérer cette recommandation dans le message SIP Ml peuvent être envisagées en variante, comme par exemple dans un autre champ du message SIP Ml (tel qu'un champ nouvellement créé pour les besoins de l'invention) ou dans un autre paramètre.
Le serveur P-CSCF 3 reçoit le message Ml contenant la recommandation RECO du serveur S-CSCF 4 quant à l'établissement du tunnel sécurisé avec le terminal 2 (étape F50).
II transmet (i.e. propage) cette recommandation RECO au terminal 2 dans un message
M2 dérivé du message Ml reçu du serveur S-CSCF 4 (étape F60). Le message M2 est donc également un message SIP 401 Unauthorized.
Dans le premier mode de réalisation décrit ici, le message M2 contient en outre des informations permettant l'établissement du tunnel sécurisé entre le terminal 2 et le serveur P-CSCF 3, indépendamment de la teneur de la recommandation RECO. De cette sorte, le serveur P-CSCF 3 s'assure que si le terminal 2 n'est pas capable d'exécuter la recommandation RECO, le tunnel sera établi en accord avec ces informations, et la protection des données échangées entre le terminal 2 et le cœur de réseau CN sera ainsi assurée.
Un exemple d'un message M2 contenant la recommandation RECO du serveur S-CSCF 4 est donné en Annexe 1 (cf. exemple Ex. 4). La recommandation est insérée dans cet exemple, dans le champ « Security-Server » du message SIP M2, sous la forme « tunnel=not_required », avec les informations permettant l'établissement du tunnel sécurisé (« ipsec-3gpp », « alg=hmac- shal-96 », etc.). Sur réception du message M2 (étape E20), le terminal 2 interprète et exécute la recommandation RECO contenue dans le message M2 (étape E30) : autrement dit ici, il n'établit pas de tunnel avec le serveur P-CSCF 3.
La recommandation élaborée par le serveur S-CSCF 4 permet donc de bloquer l'établissement du tunnel initialement prévu par le cœur de réseau CN, et ainsi de préserver les ressources du terminal 2 et du serveur P-CSCF 3.
L'enregistrement du terminal 2 auprès du cœur de réseau CN se poursuit ensuite de façon connue en soi.
Dans le premier mode de réalisation, la recommandation d'établir ou non le tunnel sécurisé entre le terminal 2 et son entité de raccordement au cœur de réseau CN (i.e. le serveur P- CSCF 3), est élaborée par le serveur S-CSCF 4.
Nous allons maintenant décrire, en référence aux figures 5 à 7 et à l'annexe 2, un second mode de réalisation, dans lequel cette recommandation est élaborée par l'entité de raccordement même du terminal au cœur de réseau, autrement dit, dans une architecture de type IMS, par le serveur P-CSCF associé au terminal.
La figure 5 représente, dans son environnement, un système de communication conforme à l'invention, dans ce second mode de réalisation.
Le système de communication comprend un terminal 2' conforme à l'invention, apte à s'enregistrer auprès d'un cœur CN' de réseau IP multimédia via un réseau d'accès AN'.
Comme précédemment pour le premier mode de réalisation, aucune limitation n'est attachée à la nature du terminal 2' ni au réseau d'accès AN' utilisé par le terminal 2' pour s'enregistrer et se connecter au cœur de réseau CN'.
Le terminal 2' dispose d'une architecture matérielle identique à celle du terminal 2, illustrée à la figure 2A décrite précédemment. Sa mémoire morte constitue un support d'enregistrement conforme à l'invention, lisible par le processeur du terminal 2' et sur lequel est enregistré un programme d'ordinateur conforme à l'invention, comportant des instructions pour l'exécution des étapes d'un procédé d'enregistrement auprès du cœur de réseau CN' conforme à l'invention, décrites ultérieurement en référence à la figure 7.
Le cœur de réseau CN' repose ici sur une architecture IMS et comprend un serveur P- CSCF 3', point d'entrée du terminal 2' sur le cœur de réseau CN', et un serveur S-CSCF 4', chargé de l'enregistrement du terminal 2' auprès du cœur de réseau CN'. Comme décrit précédemment pour le cœur de réseau CN et conformément au standard 3GPP, le cœur de réseau CN' requiert l'établissement d'un tunnel sécurisé entre le terminal 2' et l'entité de raccordement de ce terminal au cœur de réseau, autrement dit, entre le terminal 2' et le serveur P-CSCF 3' associé à ce terminal.
Le serveur P-CSCF 3' dispose ici de l'architecture matérielle d'un ordinateur, telle qu'illustrée schématiquement à la figure 6. Il comporte notamment un processeur 3A', une mémoire vive 3B', une mémoire morte 3C, une mémoire flash non volatile 3D' ainsi que des moyens de communication 3E' mettant en œuvre notamment le protocole SIP. Ces moyens de communication lui permettent de communiquer avec les entités du cœur de réseau CN' et avec le terminal 2'.
La mémoire morte 3C du serveur P-CSCF 3' constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 3A' et sur lequel est enregistré un programme d'ordinateur conforme à l'invention, comportant des instructions pour l'exécution des étapes d'un procédé d'émission d'un message conforme à l'invention décrites maintenant en référence à la figure 7.
La figure 7 illustre les principales étapes d'un procédé d'enregistrement et d'un procédé d'émission d'un message mises en œuvre respectivement par le terminal 2' et par le serveur P-CSCF 3' dans le second mode de réalisation.
Il convient de noter que les étapes mises en œuvre par le terminal 2' et représentées à la figure 7 sont identiques aux étapes mises en œuvre par le terminal 2 et représentées à la figure 3 pour le premier mode de réalisation. Elles ne seront donc pas décrites en détail ici.
Par ailleurs, par souci de simplification, on se limite dans ce second mode de réalisation, à une recommandation élaborée par le serveur P-CSCF 3' uniquement en fonction du réseau d'accès utilisé par le terminal 2' pour s'enregistrer auprès du cœur de réseau CN'. Cette hypothèse n'est toutefois pas limitative et d'autres paramètres peuvent être pris en compte, en plus du réseau d'accès utilisé par le terminal 2', pour élaborer une recommandation, comme mentionné ultérieurement dans la description.
On suppose que le terminal 2' souhaite s'enregistrer auprès du cœur de réseau CN', via le réseau d'accès AN', pour accéder par exemple à des services multimédia gérés par le cœur de réseau CN'.
A cette fin, le terminal 2' émet, via ses moyens de communications 2E', une requête d'enregistrement REGI' à destination du cœur de réseau CN' (étape ElO - Cette requête d'enregistrement REGI' est une requête SIP REGISTER.
Un exemple d'une telle requête est donné en Annexe 2 (cf. exemple Ex. 1). Elle comprend notamment un identifiant de l'utilisateur du terminal 2' dans les champs « From » et « To », ainsi qu'une information relative au réseau d'accès AN' utilisé par le terminal 2' pour s'enregistrer auprès du cœur de réseau CN'. Cette information se trouve dans le champ « P- Access-Network-Info » de la requête REGI'. Ainsi, dans l'exemple Ex. 1 de l'Annexe 2, AN' est un réseau d'accès de type 3GPP-UTRAN-TDD.
La requête REGI' émise par le terminal 2' contient également des informations relatives à l'établissement d'un tunnel sécurisé avec le serveur P-CSCF 3' du cœur de réseau CN', conformément au standard 3GPP, dans le champ « Security-Client » de la requête d'enregistrement. Ainsi, le tunnel sécurisé proposé par le terminal sera de type IPsec pour une authentification IMS AKA, et de type TLS pour une authentification SIP digest avec TLS. Par exemple, dans l'exemple Ex. 1 de l'annexe 2, l'information « ipsec-3gpp » indique qu'il s'agit du protocole IPsec. Lesdites informations peuvent comprendre également les algorithmes de chiffrement et de contrôle d'intégrité envisagés (dans l'exemple Ex. 1, il s'agit des algorithmes connus « hmac-shal-96 » et « des-ede3-cbc »), les ports sur lesquels le tunnel doit être monté, etc.
La requête d'enregistrement REGI' est reçue par le serveur P-CSCF 3' raccordant le terminal 2' au cœur de réseau CN' (étape FlO -
Sur réception de cette requête, le serveur P-CSCF 3' identifie quel réseau d'accès AN' est utilisé par le terminal 2' pour s'enregistrer auprès du cœur de réseau CN' (étape F20 . Il procède, à cette fin, de façon identique au serveur P-CSCF 3 lors de l'étape F20 du premier mode de réalisation, en utilisant l'adresse IP de transport de la requête REGI' qu'il a reçue.
Il remplace si nécessaire, l'information contenue dans le champ « P-Access-Network- Info » de la requête d'enregistrement REGI' reçue, par une information certifiée obtenue à partir de l'identification du réseau AN' déduite de l'adresse IP de transport de la requête REGI', puis transmet la requête d'enregistrement ainsi modifiée, sous la forme d'une requête REG2', au serveur S-CSCF 4' pour traitement.
Puis le serveur P-CSCF3' élabore, en fonction du réseau d'accès AN' identifié, une recommandation RECO' quant à l'établissement ou non du tunnel sécurisé avec le terminal 2' (étape F30 . Comme décrit précédemment, cette recommandation traduit le caractère opportun (c'est-à-dire utile ou obligatoire) de l'établissement du tunnel sécurisé entre le terminal 2' et le serveur P-CSCF 3' de sorte à garantir la protection et l'intégrité des données échangées entre le terminal 2' et le cœur de réseau CN'.
Cette recommandation est élaborée de façon identique à la recommandation RECO élaborée par le serveur S-CSCF 4 dans le premier mode de réalisation (cf. étape G30 décrite précédemment), en utilisant la table T, qui est, dans le second mode de réalisation, stockée dans la mémoire non volatile 3D' du serveur P-CSCF 3'.
Dans l'exemple illustré en Annexe 2, le réseau d'accès AN' utilisé par le terminal 2' est un réseau d'accès 3GPP-UTRAN-TDD. Il est associé, dans la table T, à une recommandation de ne pas établir le tunnel sécurisé entre le terminal 2' et le serveur P-CSCF 3'.
Le serveur P-CSCF 3' insère la recommandation RECO' obtenue en consultant la table
T à partir du réseau d'accès AN', dans un message M2' qu'il envoie alors au terminal 2' (étape F40 - Ce message M2', dans lequel le serveur P-CSCF 3' insère la recommandation RECO', est dérivé du message Μ SIP 401 Unauthorized de réponse intermédiaire envoyé par le serveur S- CSCF 4' à destination du terminal 2' en réponse à la requête REG2' d'enregistrement du terminal 2', et qui transite, conformément au protocole SIP, par le serveur P-CSCF 3'.
Un exemple d'un tel message M2' contenant la recommandation RECO' du serveur P- CSCF 3' est donné en Annexe 2 (cf. exemple Ex. 2). La recommandation est insérée dans cet exemple dans un champ « Security-Server » du message SIP M2', dans un paramètre « tunnel » positionné à la valeur « not_required ».
Dans le second mode de réalisation décrit ici, le message M2' contient en outre des informations permettant l'établissement du tunnel sécurisé entre le terminal 2' et le serveur P-CSCF 3', indépendamment de la teneur de la recommandation RECO'. De cette sorte, le serveur P-CSCF 3' s'assure que si le terminal 2' n'est pas capable d'exécuter la recommandation RECO', le tunnel sera établi en accord avec ces informations, et la protection des données échangées entre le terminal 2' et le cœur de réseau CN' sera ainsi assurée.
Sur réception du message M2' (étape E20 , le terminal 2' interprète et exécute la recommandation RECO' contenue dans le message M2' (étape E30 : autrement dit, dans l'exemple considéré, il n'établit pas de tunnel avec le serveur P-CSCF 3'. L'enregistrement du terminal 2' auprès du cœur de réseau CN' se poursuit de façon connue en soi.
Dans les deux modes de réalisation décrit ici, les serveurs S-CSCF 4 et P-CSCF 3' utilisent pour élaborer leur recommandation, une table T préétablie associant à divers réseaux d'accès, une recommandation quant à l'établissement ou non d'un tunnel sécurisé entre le terminal et le serveur P-CSCF raccordant le terminal au cœur de réseau. Comme mentionné précédemment, cette table T prend en compte implicitement les niveaux de sécurisation associés par le cœur de réseau aux différents réseaux d'accès.
En variante, on peut envisager d'autres manières de prendre en compte les réseaux d'accès et leurs niveaux de sécurisation pour élaborer la recommandation.
Ainsi par exemple, la recommandation peut être élaborée sur réception de la requête d'enregistrement du terminal en comparant dynamiquement des caractéristiques et/ou le type du réseau d'accès utilisé par le terminal par rapport à des critères de sécurisation prédéterminés de sorte à associer dans un premier temps au réseau d'accès un niveau de sécurisation des données, puis à déterminer si le niveau de sécurisation assuré par le réseau d'accès est suffisant pour relâcher la contrainte d'établissement du tunnel sécurisé entre le terminal et l'entité de raccordement.
Par ailleurs, dans les deux modes de réalisation décrits ici, dans la table T, seul le type à proprement parler du réseau d'accès utilisé par le terminal pour s'enregistrer auprès du cœur de réseau est en définitive pris en compte. En variante, on peut envisager de prendre en compte d'autres caractéristiques du réseau d'accès, comme par exemple l'opérateur du réseau d'accès utilisé par le terminal (notamment pour déterminer s'il s'agit du même opérateur que celui du cœur de réseau ou d'un opérateur de confiance), ou d'autres informations relatives au réseau d'accès comme par exemple si le réseau utilisé par le terminal est son réseau nominal ou un réseau visité, ou si le réseau visité et utilisé par le terminal est le réseau du serveur élaborant la recommandation ou un autre réseau, etc.
Ainsi à titre d'exemple, on peut décider d'élaborer une recommandation d'établir un tunnel sécurisé si le réseau visité utilisé par le terminal est associé par le cœur de réseau à un niveau de sécurisation faible, et inversement, une recommandation de ne pas établir de tunnel sécurisé si le réseau visité est associé par le cœur de réseau à un niveau de sécurisation fort.
Ces caractéristiques ou informations peuvent être déduites par le serveur de la requête d'enregistrement du terminal ou de la signalisation associée à cette requête, par exemple à partir du champ P-Visited-Network-Id décrit dans le document RFC 3455 édité par l'IETF.
En outre, dans un autre mode de réalisation, on peut également envisager de prendre en compte pour élaborer la recommandation, en plus du réseau d'accès utilisé par le terminal, d'autres facteurs « discriminants » ayant une influence sur le niveau de sécurisation assuré par le réseau d'accès, tels que par exemple la localisation du terminal, son utilisateur, etc. A cette fin, on peut utiliser certains paramètres contenus dans des champs de la requête d'enregistrement du terminal ou reçus avec la requête d'enregistrement, notamment dans la signalisation associée à cette requête, comme par exemple l'adresse IP du terminal, l'adresse IP de transport de la requête d'enregistrement, l'identifiant de l'utilisateur du terminal ou encore les algorithmes de chiffrement demandés dans la requête d'enregistrement par le terminal (dans le champ Security Client), et renseigner la table T de sorte à ce qu'elle traduise différentes recommandations concernant l'établissement du tunnel sécurisé en fonction de ces paramètres également.
Ainsi par exemple, pour un réseau d'accès WIFI public, on peut envisager d'avoir une recommandation « Not required » pour une première plage d'adresses IP de transport de la requête et une recommandation « Required » pour une seconde plage d'adresses IP.
De façon similaire, pour un réseau d'accès de type 3GPP, on peut envisager d'avoir une recommandation « Not required » pour l'ensemble des utilisateurs des terminaux cherchant à s'enregistrer auprès du cœur de réseau, à l'exception de certains utilisateurs pour lesquels une recommandation « Required » sera élaborée. Ces utilisateurs peuvent être identifiés par le serveur selon l'invention, par exemple en consultant leur profil utilisateur stocké au niveau du serveur HSS (Home Subscriber Server) du cœur de réseau et dans lequel une indication appropriée aura été inscrite. En parallèle, une indication pourra être intégrée dans la table T spécifiant l'existence de tels utilisateurs pour laquelle la recommandation établie en fonction du type de réseau d'accès doit être pondérée en fonction de l'identifiant de l'utilisateur du terminal.
On notera que dans la description ci-dessus, on a privilégié le réseau d'accès utilisé par le terminal comme critère principal pour élaborer la recommandation d'établir ou non le tunnel sécurisé, et considérer éventuellement à titre complémentaire d'autres paramètres tels que l'identité de l'utilisateur du terminal cherchant à s'enregistrer. Toutefois, il est possible d'inverser cet ordre de priorité, voire de ne considérer que l'un de ces paramètres comme seul critère pour élaborer la recommandation d'établir ou non le tunnel sécurisé. ANNEXE 1
Ex. 1 : requête d'enregistrement REGI du terminal 2 reçue par le serveur P-CSCF 3
REGISTER sip:home.com SIP/2.0
Via: SIP/2.0/U DP ....
P-Access-Network-Info: 3gpp-utran-TDD;utran-cell-id-3gpp=
From : <sip:bob@home.com>;tag=1234
To: <sip:bob@home.com>
Contact: <sip:AoC_bob>;expires=3600
Call-ID: 5678
Authorization: Digest username="bob private(5>home.com", realm="home.com", nonce="", uri="sip:home.com", response=""
Security-Client: ipsec-3gpp; alg=hmac-sha1 -96; ealg=des-ede3-cbc; spi-c=2482; spi-s=2483; port- c=32045; port-s=40375
Require: sec-agree
Proxy-Require: sec-agree
Cseq: 1 REGISTER
Content-Length: 0
Ex. 2 : requête d'enregistrement REG2 du terminal 2 transmise par le serveur P-CSCF
3 et reçue par le serveur S-CSCF 4
REGISTER sip:home.com SIP/2.0
Via: SIP/2.0/U DP P-CSCF....
Via: SIP/2.0/U DP ....
P-Access-Network-Info: 3gpp-utran-TDD;utran-cell-id-3gpp=
From : <sip:bob@home.com>;tag=1234
To: <sip:bob@home.com>
Contact: <sip:AoC_bob>;expires=3600
Call-ID: 5678
Authorization: Digest username="bob private@home.com", realn 'home.com", nonce="", uri="sip:home.com", response=""
Require: sec-agree
Proxy-Require: sec-agree
Cseq: 1 REGISTER
Content-Length: 0
Ex. 3 : message Ml émis par le serveur S-CSCF 4 contenant une recommandation
SIP/2.0 401 Unauthorized
Via: SIP/2.0/U DP P-CSCF....
Via: SIP/2.0/U DP ....
From : <sip:bob@home.com>;tag=1234
To: <sip:bob@home.com>;tag=rem_9876
Call-ID: 5678
WWW-Authenticate: Digest realnW'home.com", nonce="
V4pj+BE4T3J/CmetlDNW9p6hNnAQR0IDQeVyt5NQvhE=", algorithm=AKAv1 -MD5
Security-Server: tunnel=not_required
Cseq: 1 REGISTER
Content-Length: 0 Ex. 4 : message M2 transmis au terminal 2 par le serveur P-CSCF 3 contenant la recommandation du serveur S-CSCF 4
SIP/2.0 401 Unauthorized
Via: SIP/2.0/U DP ....
From : <sip:bob@home.com>;tag=1234
To: <sip:bob@home.com>;tag=rem_9876
Call-ID: 5678
WWW-Authenticate: Digest realm="home.com", nonce="
V4pj+BE4T3J/CmetlDNW9p6hNnAQR0IDQeVyt5NQvhE=", algorithm=AKAv1 -MD5
Security-Server: ipsec-3gpp; q=0.5; alg=hmac-sha1 -96; ealg=des-ede3-cbc; spi-c=5142; spi- s=5143; port-c=6045; port-s=6044;tunnel=not_required
Cseq: 1 REGISTER
Content-Length: 0
ANNEXE 2
Ex. 1 : requête d'enregistrement REGI' du terminal 2' reçue par le serveur P-CSCF 3'
REGISTER sip:home.com SIP/2.0
Via: SIP/2.0/U DP ....
P-Access-Network-Info: 3gpp-utran-TDD;utran-cell-id-3gpp=
From : <sip:bob@home.com>;tag=1234
To: <sip:bob@home.com>
Contact: <sip:AoC_bob>;expires=3600
Call-ID: 5678
Authorization: Digest username="bob private(S)home.com", realm="home.com", nonce="", uri="sip:home.com", response=""
Security-Client: ipsec-3gpp; alg=hmac-sha1 -96; ealg=des-ede3-cbc; spi-c=2482; spi-s=2483; port- c=32045; port-s=40375
Require: sec-agree
Proxy-Require: sec-agree
Cseq: 1 REGISTER
Content-Length: 0
Ex. 2 : message M 2' émis par le serveur P-CSCF 3' vers le terminal 2' contenant une recommandation
SIP/2.0 401 Unauthorized
Via: SIP/2.0/U DP ....
From : <sip:bob@home.com>;tag=1234
To: <sip:bob@home.com>;tag=rem_9876
Call-ID: 5678
WWW-Authenticate: Digest realm="home.com", nonce="
V4pj+BE4T3J/CmetlDNW9p6hNnAQR0IDQeVyt5NQvhE=", algorithm=AKAv1 -MD5
Security-Server: ipsec-3gpp; q=0.5; alg=hmac-sha1 -96; ealg=des-ede3-cbc; spi-c=5142; spi- s=5143; port-c=6045; port-s=6044;tunnel=not_required
Cseq: 1 REGISTER
Content-Length: 0

Claims

REVENDICATIONS
1. Procédé d'émission d'un message (Ml, Ml7) par un serveur (4,30 d'un cœur de réseau IP multimédia (CN,CN0 suite à la réception (G10,F100 par ledit serveur d'une requête d'enregistrement (REG2,REG10 d'un terminal (2,20 auprès du cœur de réseau, ladite requête d'enregistrement proposant une méthode d'authentification prévoyant l'établissement d'un tunnel sécurisé entre le terminal et une entité de raccordement (3,30 de ce terminal au cœur de réseau, ledit procédé d'émission comprenant :
— une étape d'identification (G20,F200 d'un réseau d'accès (ΑΝ,ΑΝΟ utilisé par le terminal pour s'enregistrer auprès du cœur de réseau IP multimédia ;
— une étape d'élaboration (G30,F300, en fonction du réseau d'accès identifié, d'une recommandation (RECO,RECO0 quant à l'établissement ou non du tunnel sécurisé entre le terminal et l'entité de raccordement pour ladite méthode d'authentification ; et
— une étape d'insertion (G40,F400 de cette recommandation dans le message émis par le serveur.
2. Procédé selon la revendication 1 dans lequel la recommandation (RECO,RECO0 est élaborée par le serveur en prenant en compte un niveau de sécurisation des données associé par le cœur de réseau au réseau d'accès.
3. Procédé selon la revendication 1 dans lequel :
— le cœur de réseau IP (CN) multimédia implémente une architecture IMS ;
— le serveur du cœur de réseau IP multimédia est un serveur S-CSCF (4) ; et
— le message (Ml) dans lequel est insérée la recommandation (RECO) est émis par le serveur S- CSCF à destination du terminal via un serveur P-CSCF (3) raccordant le terminal (2) au cœur de réseau IP multimédia.
4. Procédé selon la revendication 1 dans lequel :
— le cœur de réseau IP (CNO multimédia implémente une architecture IMS ;
— le serveur du cœur de réseau IP multimédia est un serveur P-CSCF (30 ; et
— le message (M 10 dans lequel est insérée la recommandation (RECO0 est émis vers le terminal (2).
5. Procédé selon la revendication 1 dans lequel le message émis (Ml, M 10 est conforme au protocole SIP, et la recommandation est insérée dans un champ « Security Server » de ce message.
6. Procédé selon la revendication 1 dans lequel la recommandation est élaborée en fonction également d'au moins un paramètre reçu avec la requête d'enregistrement.
7. Procédé selon la revendication 6 dans lequel ledit au moins un paramètre comprend une adresse IP de transport de la requête d'enregistrement ou un identifiant associé à un utilisateur du terminal.
8. Procédé selon la revendication 1 dans lequel le message (Ml') émis par le serveur contient en outre des informations permettant l'établissement du tunnel sécurisé entre le terminal et l'entité de raccordement de ce terminal au cœur de réseau IP multimédia.
9. Procédé selon la revendication 1 dans lequel la recommandation insérée dans le message comprend l'une des indications suivantes :
— une indication de ne pas établir le tunnel sécurisé entre le terminal et l'entité de raccordement ;
— une indication de libre choix quant à l'établissement du tunnel sécurisé entre le terminal et l'entité de raccordement ;
— une indication d'établir le tunnel sécurisé entre le terminal et l'entité de raccordement.
10. Procédé d'enregistrement d'un terminal (2,20 auprès d'un cœur de réseau IP
(CN,CN0, ledit procédé comprenant :
— une étape d'émission (E10,E100, par le terminal, d'une requête d'enregistrement (REG1,REG10 auprès du cœur de réseau, via un réseau d'accès, ladite requête d'enregistrement proposant une méthode d'authentification prévoyant l'établissement d'un tunnel sécurisé entre le terminal et une entité de raccordement (3,30 de ce terminal au cœur de réseau ;
— une étape de réception (E20,E200, par le terminal, en provenance du cœur de réseau, d'une recommandation (RECO,RECO0 quant à l'établissement ou non du tunnel sécurisé entre le terminal et l'entité de raccordement pour ladite méthode d'authentification, cette recommandation provenant d'un message (Ml, M 10 émis par un serveur (4,30 du cœur de réseau conformément à un procédé d'émission selon la revendication 1, exécuté suite à la réception de la requête d'enregistrement du terminal ; et
— une étape d'interprétation (E30,E300 de cette recommandation par le terminal.
11. Procédé de transmission destiné à être mis en œuvre par une entité de raccordement (3,30 d'un terminal (2,20 à un cœur de réseau IP multimédia (CN,CN0, ledit procédé de transmission comprenant :
— une étape de réception (F10) d'une requête d'enregistrement du terminal auprès du cœur de réseau, via un réseau d'accès, ladite requête d'enregistrement proposant une méthode d'authentification prévoyant l'établissement d'un tunnel sécurisé entre ledit terminal et ladite entité de raccordement ;
— une étape de transmission (F40) de cette requête d'enregistrement à un serveur (4,30 du cœur de réseau ;
— une étape de réception (F50), en provenance du serveur, d'un message contenant une recommandation quant à l'établissement ou non du tunnel sécurisé entre le terminal et l'entité de raccordement pour ladite méthode d'authentification, le message résultant de l'exécution par le serveur d'un procédé d'émission d'un message selon la revendication 1 ; et
— une étape de transmission (F60) de cette recommandation au terminal.
12. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé d'émission selon la revendication 1 ou du procédé d'enregistrement selon la revendication 10 ou du procédé de transmission selon la revendication 11, lorsque ledit programme est exécuté par un ordinateur.
13. Support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur selon la revendication 12.
14. Serveur (4,30 d'un cœur de réseau IP multimédia (CN,CN0, ledit serveur comprenant des moyens activés suite à la réception par le serveur d'une requête d'enregistrement
(REG2,REG10 d'un terminal (2,20 auprès du cœur de réseau, ladite requête d'enregistrement proposant une méthode d'authentification prévoyant l'établissement d'un tunnel sécurisé entre le terminal et une entité de raccordement (3,30 de ce terminal au cœur de réseau, lesdits moyens comprenant :
— des moyens d'identification d'un réseau d'accès (ΑΝ,ΑΝΟ utilisé par le terminal pour s'enregistrer auprès du cœur de réseau ;
— des moyens d'élaboration (T), en fonction du réseau d'accès identifié, d'une recommandation quant à l'établissement ou non du tunnel sécurisé entre le terminal et l'entité de raccordement pour ladite méthode d'authentification ;
— des moyens d'insertion de cette recommandation dans un message (Ml, M 10 ; et
— des moyens d'émission (4E,3E0 du message.
15. Terminal (2,20 comprenant :
— des moyens d'émission (2Ε,2Ε') d'une requête d'enregistrement (REG1,REG10 auprès d'un cœur de réseau IP multimédia (CN,CN0 via un réseau d'accès (ΑΝ,ΑΝΟ, ladite requête d'enregistrement proposant une méthode d'authentification prévoyant l'établissement d'un tunnel sécurisé entre le terminal et une entité de raccordement (3,30 de ce terminal au cœur de réseau ; — des moyens de réception (2E, 2E'), en provenance du cœur de réseau, d'une recommandation (RECO,RECO0 quant à l'établissement ou non du tunnel sécurisé entre le terminal et l'entité de raccordement pour ladite méthode d'authentification, cette recommandation provenant d'un message (Ml, Ml') émis par un serveur (4,30 du cœur de réseau conforme à la revendication 14, suite à la réception de la requête d'enregistrement ; et
— des moyens d'interprétation (2A,2A0 de cette recommandation.
16. Entité de raccordement (3) d'un terminal (2) à un cœur de réseau IP multimédia (CN), ladite entité de raccordement comprenant :
— des moyens de réception (3E) d'une requête d'enregistrement (REGI) auprès du cœur de réseau, via un réseau d'accès (AN), ladite requête d'enregistrement proposant une méthode d'authentification prévoyant l'établissement d'un tunnel sécurisé entre ledit terminal et ladite entité de raccordement ;
— des moyens de transmission (3E) de ladite requête d'enregistrement (REG2) à un serveur (4) conforme à la revendication 14 ;
— des moyens de réception (3E), en provenance du serveur, d'un message contenant une recommandation (RECO) quant à l'établissement ou non du tunnel sécurisé entre le terminal et l'entité de raccordement pour ladite méthode d'authentification ; et
— des moyens de transmission (3E) de cette recommandation audit terminal.
17. Système de communication (1,10 comprenant :
— un serveur (4,30 d'un cœur de réseau IP multimédia (CN,CN0 conforme à la revendication 14 ;
— un terminal (2,20 selon la revendication 15 apte à s'enregistrer auprès du cœur de réseau multimédia en envoyant une requête d'enregistrement (REG1,REG10 audit cœur de réseau via un réseau d'accès (ΑΝ,ΑΝΟ ; et
— une entité de raccordement (3) du terminal au cœur de réseau IP multimédia ;
ledit terminal étant apte à exécuter une recommandation élaborée par le serveur quant à l'établissement ou non d'un tunnel sécurisé entre le terminal et l'entité de raccordement du terminal au cœur de réseau.
PCT/FR2013/051504 2012-06-29 2013-06-27 Procede d'emission d'un message par un serveur d'un coeur de reseau ip|multimedia ims, et serveur WO2014001724A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
ES13744647.2T ES2694676T3 (es) 2012-06-29 2013-06-27 Procedimiento de emisión de un mensaje por un servidor de un núcleo de red IP multimedia IMS y servidor
EP13744647.2A EP2868058B1 (fr) 2012-06-29 2013-06-27 Procédé d'émission d'un message par un serveur d'un coeur de réseau ip multimedia ims, et serveur
US14/411,018 US10182037B2 (en) 2012-06-29 2013-06-27 Method for the transmission of a message by a server of an IMS multimedia IP core network, and server

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1256258 2012-06-29
FR1256258A FR2992810A1 (fr) 2012-06-29 2012-06-29 Procede d'emission d'un message par un serveur d'un coeur de reseau ip multimedia, et serveur

Publications (1)

Publication Number Publication Date
WO2014001724A1 true WO2014001724A1 (fr) 2014-01-03

Family

ID=46785696

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2013/051504 WO2014001724A1 (fr) 2012-06-29 2013-06-27 Procede d'emission d'un message par un serveur d'un coeur de reseau ip|multimedia ims, et serveur

Country Status (5)

Country Link
US (1) US10182037B2 (fr)
EP (1) EP2868058B1 (fr)
ES (1) ES2694676T3 (fr)
FR (1) FR2992810A1 (fr)
WO (1) WO2014001724A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9667779B2 (en) * 2015-06-05 2017-05-30 At&T Intellectual Property I, L.P. Routing service
EP3510803B1 (fr) * 2016-09-12 2021-04-28 Telefonaktiebolaget LM Ericsson (publ) Connexion sécurisée de couche de liaison sur des réseaux locaux sans fil
EP3949306A1 (fr) * 2019-04-02 2022-02-09 Telefonaktiebolaget Lm Ericsson (Publ) Enregistrement d'ims

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101043744B (zh) * 2006-03-21 2012-06-06 华为技术有限公司 一种ims网络中用户终端接入鉴权的方法

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7437763B2 (en) * 2003-06-05 2008-10-14 Microsoft Corporation In-context security advisor in a computing environment
FR2859862A1 (fr) * 2003-09-11 2005-03-18 France Telecom Procede de differenciation de la qualite de service dans les reseaux de communication mobile en mode paquets
US20060117388A1 (en) * 2004-11-18 2006-06-01 Nelson Catherine B System and method for modeling information security risk
US10764264B2 (en) * 2005-07-11 2020-09-01 Avaya Inc. Technique for authenticating network users
US20080095070A1 (en) * 2005-12-05 2008-04-24 Chan Tat K Accessing an IP multimedia subsystem via a wireless local area network
US8285983B2 (en) * 2006-05-15 2012-10-09 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatuses for establishing a secure channel between a user terminal and a SIP server
US20080201780A1 (en) * 2007-02-20 2008-08-21 Microsoft Corporation Risk-Based Vulnerability Assessment, Remediation and Network Access Protection
US8166534B2 (en) * 2007-05-18 2012-04-24 Microsoft Corporation Incorporating network connection security levels into firewall rules
US8265090B2 (en) * 2007-06-11 2012-09-11 Alcatel Lucent Storing access network information for an IMS user in a subscriber profile
US9444823B2 (en) * 2008-12-24 2016-09-13 Qualcomm Incorporated Method and apparatus for providing network communication association information to applications and services

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101043744B (zh) * 2006-03-21 2012-06-06 华为技术有限公司 一种ims网络中用户终端接入鉴权的方法

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"IP Multimedia Subsystem ; Stage 2", TS23.228 DU STANDARD 3GPP, 9 September 2010 (2010-09-09), Retrieved from the Internet <URL:www.3gpp.org>
"TISPAN NGN Security Subpart 3 â Security Architecture", ETSI DRAFT; 07012-3-NGN-R1V009, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE (ETSI), 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS ; FRANCE, no. V0.0.9, 21 June 2005 (2005-06-21), pages 1 - 72, XP014054305 *
TIINA KOSKINEN ET AL: "IMS-NASS bundled authentication", INTERNET CITATION, 5 September 2005 (2005-09-05), XP007904662, Retrieved from the Internet <URL:ftp://ftp.3gpp.org/TSG_SA/WG3_Security/TSGS3_40_Slovenia/Docs/S3-050548.zip> [retrieved on 20080505] *
YAN JUN ET AL: "Some comments and Proposal on IMS authentication bundled with NASS", INTERNET CITATION, 11 July 2005 (2005-07-11), XP007904661, Retrieved from the Internet <URL:http://portal.etsi.org/docbox/TISPAN/Open/Archives/Joint_meetings/2005-07_3GPP_TISPAN_Sophia/CT1-WG3/> [retrieved on 20080505] *

Also Published As

Publication number Publication date
EP2868058A1 (fr) 2015-05-06
FR2992810A1 (fr) 2014-01-03
ES2694676T3 (es) 2018-12-26
US20150150115A1 (en) 2015-05-28
EP2868058B1 (fr) 2018-08-08
US10182037B2 (en) 2019-01-15

Similar Documents

Publication Publication Date Title
EP3417591B1 (fr) Procédé et serveur de sélection d&#39;un serveur d&#39;entrée d&#39;un réseau de communication ims
EP1560368A1 (fr) Procédé d&#39;établissement d&#39;une session multimédia entre un équipement appelant et un équipement appelé d&#39;un réseau du type à sous domaine multimédia et système de communication mettant en oeuvre ce procédé
EP2291980B1 (fr) Acces reseau a distance via un reseau visite
EP3639541B1 (fr) Configuration d&#39;un terminal dans un réseau ims avec une stratégie de resélection d&#39;un type réseau
EP2920942B1 (fr) Selection de periodes de rafraichissement dans un reseau ip
EP2868058B1 (fr) Procédé d&#39;émission d&#39;un message par un serveur d&#39;un coeur de réseau ip multimedia ims, et serveur
US8776237B2 (en) Method and apparatus for end-to-end security in a heterogeneous network
EP2926524B1 (fr) Routage d&#39;une requête de service visant un abonné ims
EP2898715A1 (fr) Procedes de verification et de controle dans un c ur de reseau ip multimedia, et serveurs
FR3011423A1 (fr) Technique de restauration d&#39;un service dans un reseau
EP2873211A1 (fr) Procede d&#39;enregistrement d&#39;au moins une adresse publique dans un reseau ims et application correspondante
EP3298748A1 (fr) Procede et dispositif de traitement d&#39;un message de signalisation relatif a un service de communication d&#39;un equipement client
WO2015197937A1 (fr) Procédé de sélection dynamique par un appelant parmi une pluralité de terminaux d&#39;un appelé
FR3030958A1 (fr) Procede et dispositif de communication entre un terminal sip et un serveur web
WO2014114871A1 (fr) Enregistrement d&#39;un equipement client par l&#39;intermediaire d&#39;un serveur mandataire dans un reseau de communication
EP2801178B1 (fr) Procédé dynamique de détermination d&#39;une liste de services dans un réseau sip
WO2014170582A1 (fr) Procede de restauration de service dans un reseau ims
EP3583757A1 (fr) Procédé de changement de réseau mobile
FR2912584A1 (fr) Reseau ims autorisant la portabilite d&#39;identifiants publics d&#39;utilisateurs.
WO2009125150A1 (fr) Procede et dispositif de communication tenant compte d&#39;un controle de la validite d&#39;une demande d&#39;allocation de bande passante dans une architecture reseau
FR2881593A1 (fr) Procede et systeme d&#39;enregistrement d&#39;utilisations, serveur hss et serveur d&#39;application d&#39;un reseau ims

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13744647

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2013744647

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 14411018

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE