WO2005039141A1 - Verfaren zur sicherung des datenverkehrs zwischen einem mobilfunknetz und einem ims-netz - Google Patents

Verfaren zur sicherung des datenverkehrs zwischen einem mobilfunknetz und einem ims-netz Download PDF

Info

Publication number
WO2005039141A1
WO2005039141A1 PCT/EP2004/052527 EP2004052527W WO2005039141A1 WO 2005039141 A1 WO2005039141 A1 WO 2005039141A1 EP 2004052527 W EP2004052527 W EP 2004052527W WO 2005039141 A1 WO2005039141 A1 WO 2005039141A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
ims
ims network
mobile subscriber
mobile
Prior art date
Application number
PCT/EP2004/052527
Other languages
English (en)
French (fr)
Inventor
Dirk Kröselberg
Original Assignee
Siemens Aktiengesellschaft
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
Priority claimed from DE10356091A external-priority patent/DE10356091A1/de
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to EP04791217.5A priority Critical patent/EP1673921B1/de
Priority to US10/575,884 priority patent/US7466976B2/en
Priority to JP2006534758A priority patent/JP4384177B2/ja
Publication of WO2005039141A1 publication Critical patent/WO2005039141A1/de

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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08—Upper layer protocols
    • H04W80/10—Upper layer protocols adapted for application session management, e.g. SIP [Session Initiation Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/02—Inter-networking arrangements

Definitions

  • the invention relates to a method for securing data traffic between a mobile radio network and an IMS network and a corresponding data network.
  • IMS IP-based Multimedia Subsystem
  • IMS-AKA Authentication and Key Agreement
  • IMS Release 5 a security architecture is used, in which key material is contained in a so-called ISIM (IP Multimedia Services Identity Module) on the chip card of the subscriber's mobile device, this key material also being stored in computers in the IMS network.
  • ISIM IP Multimedia Services Identity Module
  • the object of the invention is therefore to provide a method for securing data traffic between a mobile radio network and an IMS network, which enables the provision of identical key material for the IMS network and the mobile subscriber in a simple manner.
  • Confirmation messages are known from the prior art; reference is made here, for example, to document [2].
  • the confirmation message is preferably a random value.
  • Mobile subscribers and the IMS network are then used a security protocol protected by a common key, the key for the security protocol being derived from the confirmation message.
  • the invention is based on the idea of using a confirmation message used for checking the identity in a security report as a key, so that it is no longer necessary to separately provide identical keys for the mobile subscriber and the IMS network.
  • the key for the security protocol is the confirmation message itself, i. H . deriving the key from the confirmation message consists in using the confirmation message as a key. In this way, a particularly simple implementation of the method according to the invention is achieved.
  • the key is a shared secret between the IMS network and the mobile subscriber. The authentication is therefore carried out without further input from the mobile subscriber.
  • the key can be a password that can be entered by the mobile subscriber.
  • HTTP digest is also used as a particularly preferred security protocol, this protocol likewise being sufficiently known from the prior art.
  • the invention further relates to a data network which comprises a mobile radio network and an IMS network, the data network being designed in such a way that the data traffic between the mobile radio network and the IMS network is secured in accordance with the method according to the invention.
  • the mobile radio network which forms part of the data network, is preferably a GFRS and / or UMTS network.
  • FIG. 1 shows the schematic structure of a data network in which the data backup method according to the invention can be used
  • FIG. 2 shows a message flow according to the IMS-AKA protocol known from the prior art
  • FIG. 3 shows a schematic sketch which explains the method according to the invention.
  • Figure 4 shows a message flow s according to the inventive method.
  • UE User Equipment
  • GPRS General Package Radio Service
  • a subnet 3 connects to the air interfaces and, depending on the air interface used, can be a GPRS or a UMTS network.
  • RADIUS Radius server
  • DHCP Dynamic Host Configuration Protocol
  • the individual components of the subnet 3 are well-known components from a GPRS or UMTS network, so that the individual functions of the components are not discussed in detail here. It should only be noted that the user data of the user are stored in the HLR server and can be called up when the device UE is registered with the user's SIM card in the network, as a result of which the user is authenticated in the network 3.
  • the individual components of the IMS network are also known from the prior art, so that they are not explained in more detail here.
  • the IMS network provides value-added services for the user of the UE device. These services are, in particular, multimedia services that are made available to the user via the application server AS.
  • a further (not specified) subnet 5 also connects to the subnet 4.
  • the HSS server HSS in the network 4 represents the analog to the server HLR in the network 3, user profiles for registration and authentication in the IMS network 4 being stored in the HSS server.
  • IMS versions 5 and 6 3GPP specifications are specified.
  • One of these specifications is the IMS-AKA protocol.
  • the message flow of this protocol is shown in FIG. 2, the exact names of the messages not being discussed in detail since these are familiar to the person skilled in the art.
  • a register message is first sent from the user terminal UE via the computers P-CSCF, I-CSCF, HSS to the computer S-CSCF. With this message, the terminal UE informs the IMS network that it wants to register in this network. The message is transmitted in the SIP protocol and contains the SIP identity of the user terminal UE.
  • the HSS computer checks whether it has stored user data relating to the SIP identity of the AV request and sends an appropriate AV request response back to the S-CSCF computer.
  • the AKA authentication then runs by sending authentication messages between the terminal UE and the server S-CSCF. With this authentication, a so-called auth challenge is first sent to the UE, whereupon a reply is received with a register message. Is authentication successful, an Auth-OK is sent back to the UE and the data exchange can then take place.
  • the user of the UE and the network are mutually authenticated and two keys are generated which are used in the IMS network after the authentication to protect subsequent signaling messages.
  • K-messages can also be exchanged between the mobile user of the UE terminal and an application server in the network.
  • the user can use the HTTP protocol to communicate with an application server AS in the form of an HTTP server.
  • the Application Server AS is used for administration purposes or for other applications.
  • examples of such other applications are a walkie-talkie conversation via push-to-talk over cellular (PoC), the access lists on data servers and the like.
  • Other applications are buddy
  • HTTP digest HyperText Transfer Protocol
  • HTTP digest HyperText Transfer Protocol
  • the data exchange shown schematically in FIG. 3 according to the method according to the invention arose within the framework of the standardization of the service PoC (Push-o-Talk Over Cellular), which is developed by the OMA (Open Mobile Alliance).
  • PoC Push-o-Talk Over Cellular
  • OMA Open Mobile Alliance
  • This standardization specifies IMS-based applications that use HTTP digest as the security protocol. HTTP-Digest can protect both HTTP-based and SIP-based communication.
  • the relevant specifications for PoC can be found in documents [4], [5] and [6].
  • the method shown in FIG. 3 is also based on data traffic security methods known from the prior art, which are described in particular in documents [2] and [7] and were developed by the applicant.
  • FIG. 3 shows the components of the data network shown in FIG. 1 which are relevant for data traffic security.
  • a user of the mobile terminal UE first logs on to the. GPRS network 3 via the air interface 2.
  • the user authenticates himself using his SIM card and a secure PDP context is established with the GPRS network.
  • an IP address is assigned to the mobile subscriber.
  • the PDP context represents a data tunnel in which data packets are transmitted to the GPRS network 3 via the air interface.
  • the identity MSISDN of the terminal UE in the GPRS network is also known in the GPRS network.
  • the IP address and this identity MSISDN are transmitted to the HSS server via a radius server.
  • the server HSS can determine the correspondingly assigned IMS identity of the device UE and assign it to the currently assigned IP address.
  • the assigned IP address and the IMS identity are then transmitted from the HSS to the S-CSCF server.
  • the user terminal UE also registers with the P-CSCF server of the IMS network, this registration being indicated by the arrow labeled "IMS-Registration" in FIG. 3. With this registration, the actually used IP address of the IMS user becomes known to the P-CSCF server.
  • the P-SCSF server sends this IP address to the S-CSCF server, which checks whether this IP address and the IP address transmitted by the HSS are identical and correspond to the IMS identity specified during IMS registration.
  • This check can ensure that an IMS user does not assume the identity of another IMS user. He gives the verification that the IP addresses are assigned to the same IMS identity, a confirmation message is exchanged between HSS and S-CSCF in the form of a token.
  • the token is generated by a random generator and is a 128-bit random value. However, other values with random properties are also conceivable for the token.
  • the method just described corresponds to the method already described in document [7].
  • the token is not used directly for data backup between the UE and the IMS network. Rather, the token is used in the method according to the invention as a common key for a further security protocol which is used between the terminal UE and the IMS network.
  • the security protocol HTTP digest is used. To use the token for this, it is first transmitted to the user terminal UE via the GPRS network and the GPRS air interface.
  • the GPRS air interface uses an encrypted transmission, so that it can be assumed that the token will be securely transmitted to the UE instead.
  • es ie from the S-CSCF to the point at which the encryption of the air interface starts in the GPRS network, a transmission in a secure network infrastructure is initially assumed.
  • This security can be achieved, for example, by known protection mechanisms such as firewalls. If you cannot assume sufficient security within this infrastructure, additional security protocols such as IPsec can be used (see document [8]).
  • HTTP digest can thus be used as a security protocol without a common secret being made available both for the IMS network and for the terminal UE by means of complex mechanisms beforehand. Rather, the fact is used that in the method according to the invention, based on the already existing GPRS key infrastructure, a token is generated in advance, which can be used as a shared secret for HTTP digest.
  • FIG. 4 shows the message flow with which a user registered in the GPRS network of FIG. 3 registers with the IMS network.
  • the user terminal UE sends a register message via the P-CSCF and the I-CSCF to the S-CSCF of the GPRS network.
  • IMS_GPRS_Key_Distr by means of which the network is informed that the experience according to the invention for securing the data transmission jars should be used.
  • this can also be achieved in other ways, for example by permanently configuring the networks or by using other headers or parameters in the register message.
  • the authenticity of the message is then checked in the S-CSCF. As explained above, this is done by comparing the IP address determined in the P-CSCF with the IP address determined in the HSS and the corresponding IMS identities. If the IMS identity matches, an AV request is sent to the HSS of the IMS network. Finally, an AV response is sent back to the S-CSCF.
  • This reply message contains a token. According to document [7], this token is sent to the user in an unauthorized message.
  • the air interface between the terminal UE and the -CSCF server of the GPRS network is indicated by a gray area.
  • the data transmission over the air interface is encrypted using known mechanisms.
  • the transmission of the token to the terminal UE via the GPRS interface is protected.
  • the token is transmitted in an HTTP digest header.
  • the token can also be transmitted in another header or parameter that is independent of the HTTP digest header.
  • the token can also be transmitted in a separate message.
  • the user terminal UE then sends a register message to the computer S-CSCF via the servers P-CSCF and I-CSCF.
  • This register message is secured with the HTTP-Digest security protocol, the previously transmitted token being used as a shared secret between the terminal UE and the server S-CSCF. This is possible because the ToJten by transmitting the previous register message both in the device UE and in the S-CSCF is known.
  • the authentication of the terminal UE takes place in the IMS network, which is designated AU in FIG. 4.
  • the S-CSCF sends back to the UE a confirmation OK.
  • the actual data exchange between the UE and the IMS network can then begin, this data exchange being secured via HTTP digest.
  • FIG. 4 shows an example of an invite message that is sent in the further data exchange.
  • HTTP digest is used as a security mechanism for IMS signaling.
  • other security mechanisms could also be used for IMS signaling, provided that these security mechanisms use dynamic keys or passwords.
  • CMS Chemical Message Syntax
  • the method according to the invention can in particular also be used to secure HTTP-based communication with application servers. It is assumed that the user is currently logged on to an IMS network or at least was logged on and has a valid token that has been accepted by the IMS network. If a user now communicates via the UE terminal with an HTTP-based application server which is connected to the IMS network, HTTP digest can be used to secure the HTTP messages, the token being used as the password for HTTP digest , So that the HTTP server is able to check the message protected by HTTP digest, it also needs this token. For this purpose, it is either sent from the S-CSCF or from the HSS of the IMS network to the application server. Corresponding interfaces for this are known. Thus, both for SIP signaling and for HTTP signaling for responses from the IMS network or from an HTTP
  • HTTP digest can be used in the opposite direction, so that, for example, the terminal UE sends an unauthorized message to the S-CSCF in the IMS network.
  • 3GPP SA3 (Security) (2002-09): "Network domain security; IP network layer security (Release 5)", Technical specification 33.210 v5.3.0

Landscapes

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

Abstract

Die Erfindung betrifft ein Verfahren zur Sicherung des Datenverkehrs zwischen einem Mobilfunknetz (3) und einem IMS-Netz (4), bei dem sich ein mobiler Teilnehmer (UE) im Mobilfunknetz (3) authentifiziert, bei dem sich der mobile Teilnehmer (UE) im IMS-Netz (4) authentifiziert, bei dem überprüft wird, ob die Identität des im IMS-Netz (4) authentifizierten mobilen Teilnehmers (UE) mit der Identität des im Mobilfunknetz (3) authentifizierten Teilnehmers (UE) übereinstimmt, bei dem im Falle übereinstimmender Identitäten eine Bestätigungsnachricht von dem IMS-Netz (4) an den mobilen Teilnehmer (UE) gesendet wird und bei dem ein Datenaustausch zwischen dem mobilen Teilnehmer (UE) und dem IMS-Netz (4) über ein durch einen gemeinsamen Schlüssel geschütztes Sicherheitsprotokoll erfolgt, wobei der Schlüssel für das Sicherheitsprotokoll aus der Bestätigungsnachricht abgeleitet wird.

Description

Beschreibung
Verfahren zur Sicherung des Datenverkehrs zwischen einem Mobilfunknetz und einem IMS-Netz
Die Erfindung betrifft ein Verfahren zur Sicherung des Datenverkehrs zwischen ein Mobilfunknetz und einem IMS-Netz sowie ein entsprechendes Datennetz.
Das in der 3GPP-Organisation (3GPP = 3rd Generation Partners- hip Project) standardisierte IMS-Subnetz (IMS = IP-based Multimedia Subsystem) stellt einem mobilen Teilnehmer in einem Mobilfunknetz Multimedia-Dienste zur Verfügung. Um eine authentifizierte Anmeldung eines mobilen Teilnehmers in einem IMS-Netz zu erreichen, ist aus dem Stand der Technik das IMS- AKA-Protokoll (AKA = Authentification and Key Agreement) bekannt (siehe Dokument [1] ) . Im IMS Release 5 wird eine Sicherheitsarchitektur verwendet, in der Schlüsselmaterial in einem sogenannten ISIM (IP Multimedia Services Identity Modu- le) auf der Chipkarte des mobilen Endgeräts des Teilnehmers enthalten ist, wobei dieses Schlüsselmaterial ferner in Rechnern im IMS-Netz abgespeichert ist. Es ist hierbei nachteilhaft, dass ein Mechanismus bereitgestellt werden muss, mit dem erreicht wird, dass im Netz und auf dem ISIM das identi- sehe Schlüsselmaterial abgespeichert ist.
Aufgabe der Erfindung ist es deshalb, ein Verfahren zur Datenverkehrssicherung zwischen einem Mobilfunknetz und einem IMS-Netz zu schaffen, welches auf einfache Weise die Bereit- Stellung von identischem Schlüsselmaterial für das IMS-Netz und den mobilen Teilnehmer ermöglicht.
Diese Aufgabe wird durch die unabhängigen Patentansprüche gelöst . Weiterbildungen der Erfindung sind in den abhängigen Ansprüchen definiert. In dem erfindungsgemäßen Verfahren zur Sicherung des Datenverkehrs authentifiziert sich zunächst ein mobiler Teilnehmer im Mobil unknetz. Anschließend wird der mobile Teilnehmer im IMS-Netz authentifiziert. Schließlich wird überprüft, ob die Identität des im IMS-Netz authentifizierten mobilen Teilnehmers mit der Identität des im Mobilfunknetz identifizierten Teilnehmers übereinstimmt. Im Falle übereinstimmender Identitäten wird eine Bestätiguncjsnacϊiricht zwischen dem mobilen Teilnehmer und dem IMS-Netz ausgetauscht. Die Überprüfung der Identität des mobilen Teilnehmers sowie der Austausch einer
Bestätigungsnachricht sind aus dem Stand der Technik bekannt, es sei hier beispielhaft auf das Dokument [2] verwiesen. Vorzugsweise ist die Bestätigungsnachricht ein Zufallswert. Beim Datenaustausch zwischen dem. mobilen Teilnehmer und dem IMS- Netz wird anschließend ein durch einen gemeinsamen Schlüssel geschütztes Sicherheitsprotokoll verwendet, wobei der Schlüssel für das Sicherheitsprotokoll aus der Bestätigungsnachricht abgeleitet wird. Der Erfindung liegt die Idee zugrunde, eine bei der Überprüfung der Identität verwendete Bestäti- gungsnachricht in einem Sirfierheits—protokoll als Schlüssel einzusetzen, so dass es niσϊαt mehr notwendig ist, separat i- dentische Schlüssel für den mobilen Teilnehmer und das IMS- Netz bereitzustellen.
In einer besonders bevorzugten Ausfüh ungsform der Erfindung ist der Schlüssel für das Sicherheitsprotokoll die Bestätigungsnachricht selbst, d. h . die Ableitung des Schlüssels aus der Bestätigungsnachricht besteht in der Verwendung der Bestätigungsnachricht als Schlüssel. Hierdurch wird eine beson- ders einfache Implementation des er indungsgemäßen Verfahrens erreicht .
In einer weiteren Ausführuncjsform der Erfindung ist der Schlüssel ein gemeinsames Geheimnis zwischen dem IMS-Netz und dem mobilen Teilnehmer. Die Authentifizierung erfolgt somit ohne weitere Eingaben des mobilen Teilnehmers . Alternativ kann der Schlüssel ein von dem mobilen Teilnehmer eingebbares Passwort sein.
In einer weiteren Ausgestaltung des erfindungsgemäßen Verfah- rens erfolgt die Authentifizierung des mobilen Teilnehmers im IMS-Netz über das hinlänglich aus dem Stand der Technik bekannte SIP-Protokoll (SIP = Session Initiation Protocol) bzw. über das ebenfalls bekannte HTTP—Protokoll . Ferner wird als besonders bevorzugtes Sicherheitsprotσkoll HTTP-Digest ver- wendet, wobei dieses Protokoll ebenfalls hinlänglich aus dem Stand der Technik bekannt ist.
Neben dem oben beschriebenen Verfahren zur Datenverkehrssicherung betrifft die Erfindung ferner ein Datennetz, welches ein Mobilfunknetz und ein IMS-Netz umfasst, wobei das Datennetz derart ausgestaltet ist, dass der Datenverkehr zwischen dem Mobilfunknetz und dem IMS-Netz gemäß dem erfindungsgemäßen Verfahren gesichert ist. Das Mobilfunknetz, welches einen Teil des Datennetzes bildet, ist dabei vorzugsweise ein GFRS- und/oder UMTS-Netz.
Ausführungsbeispiele der Erfindung werden nachfolgend anhand der beigefügten Zeichnungen beschrieben.
Es zeigen:
Figur 1 den schematischen Aufbau eines Datennetzes, in dem das erfindungsgemäße Datensicherungsverfahren eingesetzt werden kann;
Figur 2 einen Nachrichtenfluss gemäß dem aus dem Stand der Technik bekannten IMS-AKA-Protokoll
Figur 3 eine schematische Skizze, welche das er indungsge- mäße Verfahren erläutert; und Figur 4 einen Nachrichtenflus s gemäß dem erfindungsgemäßen Verfahren .
Figur 1 zeigt ein Datennetz, bei dem Daten zwischen einem Be— nutzerendgerät UE (UE = User Equipment) und einer Mehrzahl von Subnetzen eines Datennetzes ausgetauscht werden. Das Datennetz umfasst Luftschnittstellen 1 und 2 , wobei es sich bei der Schnittstelle 1 um eine UMTS-Schnittstelle und bei der Schnittstelle 2 um eine GPRS-Schnittstelle handelt (UMTS = Universal Mobile Telecommunicat ion System; GPRS = General Pa- ckage Radio Service) . Über die Luftschnittstellen erfolgt eine verschlüsselte Übertragung.
An die Luftschnittstellen schließt sich ein Subnetz 3 an, welches je nach verwendeter Lu tschnittstelle ein GPRS— bzw. ein UMTS-Netz sein kann. Ein solches Netz umfasst als Eingangsrechner einen SGSN-Server SGSN (SGSN = Serving GPRS Support Node), an den sich ein GGSN-Server GGSN (GGSN = Gateway GPRS Support Node) sowie ein HLR-Server HLR (HLR = Home Loca- tion Register) anschließt. Der GGSN-Server ist wiederum mit einem Radius-Server RADIUS, einem DHCP-Server DHCP (DHCP = Dynamic Host Configuration Protocol), einem Router R sowie mit dem Internet verbunden. Die einzelnen Komponenten des Subnetzes 3 sind allseits bekannte Komponenten aus einem GPRS- bzw. UMTS-Netz, so dass auf die einzelnen Funktionen der Komponenten an dieser Stelle nicht näher eingegangen wird. Es sei lediglich angemerkt, dass in dem HLR-Server die Benutzerdaten des Benutzers gespeichert sind und bei der Registrierung des Gerätes UE mit der SIM-Karte des Benutzers im Netz abgerufen werden können, wodurch eine Authentifizierung des Benutzers im Netz 3 erfolgt .
An das Subnetz 3 schließt sich ein IMS-Netz 4 an, welches über den Server HSS (HSS = Home Subscriber Server) bzw. den Ethernet-Switch ES mit dem Subnetz 3 verbunden ist. Das IMS- Netz umfasst als weitere Komponenten ferner den Domain-Name- Server DNS, die Server P-/I-/S-CSCF (CSCF = Call Session Control Function) sowie die Applikationsserver AS. Die einzelnen Komponenten des IMS-Netzes sind ebenfalls aus dem Stand der Technik bekannt, so dass sie hier nicht näher erläutert werden. Das IMS-Netz stellt Mehrwertdienste für den Benutzer des Endgeräts UE zur Verfügung. Bei diesen Diensten handelt es sich insbesondere um Multimedia-Dienste, die über die ApplikationsServer AS dem Benutzer bereitgestellt werden. An das Subnetz 4 schließt sich ferner ein weiteres (nicht näher spezifiziertes) Subnetz 5 an. Der HSS-Server HSS im Netz 4 stellt das Analogon zum Server HLR im Netz 3 dar, wobei im HSS-Server Benutzerprofile für die Registrierung und Authentifizierung im IMS-Netz 4 gespeichert sind.
Zur Datenverkehrssicherung sind in den IMS—Versionen 5 bzw. 6 3GPP-Spezifikationen festgeleg . Eine dieser Spezifikationen ist das IMS-AKA-Protokoll . Der Nachrichtenfluss dieses Protokolls ist in Figur 2 dargestellt, wobei auf die genauen Bezeichnungen der Nachrichten nicht näher eingegangen wird, da diese dem Fachmann geläufig sind. In diesem Protokoll erfolgt zunächst das Aussenden einer Register—Nachricht von dem Benutzerendgerät UE über die Rechner P-CSCF, I-CSCF, HSS zum Rechner S-CSCF. Mit dieser Nachricht teilt das Endgerät UE dem IMS-Netz mit, dass es sich, in diesem Netz registrieren möchte. Die Nachricht wird im SIP-Protokoll übertragen und enthält die SIP-ldentität des Benutzerendgeräts UE . Der Rechner S-CSCF sendet anschließend- einen sogenannten AV-Request (AV = Authentifikation Vector) an den Rechner HSS, wobei dieser AV-Request wiederum die SIP—Identität des Benutzerendgeräts UE enthält. Der Rechner HSS überprüft anschließend, ob er Benutzerdaten zu der SIP-ldentität des AV-Requests gespeichert hat und schickt eine en sprechenden AV-Request-Response an den S-CSCF-Rechner zurück. Anschließend läuft die AKA- Authentifizierung über das Aussenden von Authentifizierungs- nachrichten zwischen dem Endgerät UE und dem Server S-CSCF. Bei dieser Authentifizierung wird zunächst ein sogenannter Auth-Challenge an das UE geschickt, woraufhin mit einer Register-Nachricht geantwortet wird. Ist die Authentifizierung erfolgreich, wird ein Auth-OK an das UE zurückgesendet und der Datenaustausch kann anschließend erfolgen. Im IMS—AKA- Protokoll werden der Benutzer des Endgeräts UE und das Netz gegenseitig authentifiziert und es werden zwei Schlüssel ge- neriert, die im Anschluss an die Authentifizierung zum Schutz nachfolgender Signalisierungsnac richten im IMS-Netz verwendet werden .
Neben dem Schutz der reinen IMS—S IP—Signalisierungs— nachrichten gemäß dem IMS-AKA-Protokoll können darüber hinaus zwischen dem mobilen Benutzer des Endgeräts UE und einem Applikationsserver im Netz weitere KTachrichten ausgetauscht werden. Beispielsweise kann der Benutzer über das HTTP- Protokoll mit einem ApplikationsServer AS in der Form eines HTTP—Servers kommunizieren. Der ApplikationsServer AS wird hierbei zu Administrationszwecken oder für andere Anwendungen verwendet . Beispiele solcher anderen Anwendungen sind neben dem Austausch des HTTP-Protokolls ein Walkie-Talkie-Gespräch über Push-to-Talk Over Cellular (PoC) , die Zugrif slisten auf Datenservern und ähnliches. Weitere Anwendungen sind Buddy-
Listen von Chat-Applikationen sowie Gruppenmanagement—Dienste oder Konferenzschaltungen.
Zum Austausch von gesicherten Nachrichten zwischen einem Ap- plikationsserver AS und einem Benutzerendgerät UE können bekannte Sicherheitsprotokolle, wie HTTP-Digest oder ähnliches verwendet werden. Bei diesen Protokollen ist es erforderlich, dass sowohl das Benutzerendgerät als auch der Applikationsserver über gemeinsames Schlüsselmaterial bzw. Passwörter verfügen, welche vor dem Aussenden, der ersten gesicherten
Nachricht beiden zur Verfügung stehen müssen. Eine Lösung, um zwischen einem Applikationsserver AS und einem Benutzerendgerät UE gesichert Daten auszutauschen, besteht darin, dass die Schlüssel für die gesicherte Datenübertragung aus der bereits bestehenden Schlüsselinfrastruktur der Netzbetreiber abgeleitet wird (siehe Dokument [3]) . Da die in Dokument [3] beschriebene Lösung erst mit dem 3GPP Release 6 verfügbar ist und in nächster Zeit nicht unterstüt zt wird, wird bei der nachfolgend beschriebenen Aus führungs form des er findungs gemäßen Datenverkehrs-Sicherungsverfahrens eine alternative Lösung unter Verwendung bereits exist ierender Schlüs selinf ra— Struktur beschrieben .
Der in Figur 3 schematisch dargestellte Datenaustausch gemäß dem erfindungsgemäßen Verfahren ent stand im Rahmen der Standardisierung des Dienstes PoC (Push— o— Talk Over Cellular) , der von der OMA (Open Mobile Alliance ) entwickelt wird . Bei dies er Standardisierung werden IMS-basierte Applikationen spez ifiziert , die als Sicherheitsprotokoll HTTP-Digest verwenden . HTTP-Digest kann sowohl HTTP-basierte als auch SIP- basierte Kommunikation s chüt zen . Die relevant en Spezi ikatio- nen zu PoC finden sich in den Dokumenten [ 4] , [ 5 ] und [ 6 ] . Das in Figur 3 dargest ellte Verfahren set zt ferner auf bereit s aus dem Stand der Technik bekannte Datenverkehrs - Sicherungsverfahren auf, die insbes ondere in den Dokumenten [ 2 ] und [ 7 ] beschrieben sind und von dem Anmelder entwickelt wurden .
In Figur 3 sind die für die Datenverkehrssicherung relevanten Komponenten des in Figur 1 dargestellten Datennetzes wiedergegeben. Gemäß Figur 3 meldet sich ein Benutzer des mobilen Endgeräts UE zunächst an dem. GPRS-Netz 3 über die Luftschnittstelle 2 an. Im Rahmen dieser Anmeldung authentifiziert sich der Benutzer mittels seiner SIM-Karte und es wird ein gesicherter PDP—Kontext mit dem GPRS— etz aufgebaut . Ferner wird dem mobilen Teilnehmer eine IP-Adresse zugewiesen. Der PDP-Kontext stellt einen Datentunnel dar, in dem Datenpakete über die Luftschnittstelle an das GPRS-Netz 3 übermittelt werden.
Im GPRS-Netz ist neben der zugewiesenen IP-Adresse auch noch die Identität MSISDN des Endgeräts UE im GPRS-Netz bekannt. Die IP-Adresse und diese Identität MSISDN werden über einen Radius-Server an den HSS-Server übermittelt. Aus der GPRS- Identität MSISDN kann der Server HSS die entsprechend zugeordnete IMS—Identität des Geräts UE ermitteln und der aktuell zugewiesene IP-Adresse zuordnen. Die zugewiesene IP-Adresse und die IMS—Identität werden anschließend vom HSS an den S-CSCF-Server übermittelt.
Das Benutzerendgerät UE registriert sich ferner an dem P-CSCF-Server des IMS-Netzes, wobei diese Registrierung durch den mit "IMS—Registration" bezeichneten Pfeil in Figur 3 an— gedeutet ist. Bei dieser Registrierung wird die tatsächlich verwendete IP-Adresse des IMS-Nuttzers dem P-CSCF-Server bekannt. Der P-SCSF-Sever sendet diese IP-Adresse an den S-CSCF-Server, der überprüft, ob diese IP-Adresse und die vom HSS übermittelte IP-Adresse identisch sind und der bei der IMS-Registrierung angegebenen IMS—Identität entsprechen.
Durch diese Überprüfung kann sichergestellt werden, dass ein IMS-Benutzer nicht die Identität eines anderen IMS-Benutzers annimmt. Er gibt die Überprüfung, dass die IP-Adressen der gleichen IMS-Identität zugeordnet sind, wird zwischen HSS und S-CSCF eine Bestätigungsnachricht in Form eines Tokens ausgetauscht. Der Token wird hierbei durch einen Zufallsgenerator erzeugt und ist ein 128 Bit langer Zufallswert. Allerdings sind für den token auch andere Werte denkbar, die Zufallseigenschaften besitzen.
Bis zu diesem Schritt entspricht das soeben beschriebene Verfahren dem bereits im Dokument [7] beschriebenen Verfahren. Im Unterschied zu dem Verfahren in Dokument [7] wird der Token jedoch nicht direkt zur Datensicherung zwischen dem UE und dem IMS-Netz eingesetzt. Vielmehr wird im erfindungsgemäßen Verfahren der Token als gemeinsamer Schlüssel für ein weiteres Sicherheitsprotokoll verwendet, das zwischen dem Endgerät UE und dem IMS-Netz eingesetzt wird. In der hier beschriebenen Ausführungsform wird dabei das Sicherheitsproto— koll HTTP-Digest verwendet. Um den Token hierfür einzusetzen, wird dieser zunächst über das GPRS-Netz und die GPRS- Luftschnittstelle an das Benutzerendgerät UE übermittelt. Die GPRS-Luftschnittstelle verwendet eine verschlüsselte Übertragung, so dass man davon ausgehen kann, dass eine sichere Übermittlung des Tokens an das Endgerät UE statt indet . Innerhalb des IMS-/GPRS-Netz: es, d.h. vom S-CSCF bis zu dem Punkt, an dem im GPRS-Netz die Verschlüsselung der Luftschnittstelle einsetzt, wird zunächst von einer Übertragung in einer gesicherten Netzinfrastruktur ausgegangen. Diese Sicherheit kann z.B. durch bekannte Schutzmechanismen wie Firewalls erreicht werden. Kann man nicht von einer ausreichenden Sicherheit innerhalb dieser Infrastruktur ausgehen, so können zusätzliche Sicherungsprotokolle wie IPsec verwendet werden (siehe Dokument [8]) .
Nunmehr kennen sowohl das IMS-Netz als auch das Endgerät UE den Token und besitzen somit ein gemeinsames Geheimnis. Dieser Token kann folglich als Schlüssel für HTTP-Digest eingesetzt werden, wobei hierzu die 32-Character-Hex-Codierung in Textdarstellung für den Token verwendet wird. Durch das erfindungsgemäße Verfahren kann somit HTTP-Digest als Sicher- heitsprotokoll eingesetzt werden, ohne dass durch aufwändige Mechanismen zuvor ein gemeinsames Geheimnis sowohl für das IMS-Netz als auch für das Endgerät UE bereitgestellt wird. Es wird sich vielmehr die Tatsache zunutze gemacht, dass im erfindungsgemäßen Verfahren, basierend auf der bereits existie- renden GPRS-Schlüsselinf astruktur, im Vorfeld ein Token erzeugt wird, der für HTTP-Digest als gemeinsames Geheimnis genutzt werden kann.
In Figur 4 ist der Nachrichtenfluss gezeigt, mit dem sich ein in dem GPRS-Netz der Figur 3 registrierter Benutzer am IMS- Netz registriert. Zunächst wird vom Benutzerendgerät UE eine Register-Nachricht über den P-CSCF und den I-CSCF an den S-CSCF des GPRS-Netzes gesendet. Die Register-Nachricht beinhaltet die IMS-Identität ΣMS-ID des Benutzers und einen HTTP- Digest Authorization-Header mit dem Parameter auth-param =
"IMS_GPRS_Key_Distr", durch den dem Netz angezeigt wird, dass das erfindungsgemäße erfahren zur Sicherung des Datenver- kehrs verwendet werden soll. Dies kann jedoch auch auf andere Weise erreicht werden, zum Beispiel durch feste Konfiguration der Netze oder durch andere Header bzw. Parameter in der Register-Nachricht .
Anschließend wird die Authentizität der Nachricht im S-CSCF überprüft. Dies geschieht - wie zuvor erläutert - durch Vergleichen der im P-CSCF ermittelten IP-Adresse mit der im HSS ermittelten IP-Adresse sowie der entsprechenden IMS— Identitäten. Bei übereinstimmender IMS-Identität wird ein sogenannter AV-Request an den HSS des IMS-Netzes gesendet. Schließlich wird ein AV-Response an den S-CSCF zurückgesendet. Diese Antwort— achricht beinhaltet einen Token. Dieser Token wird entsprechend dem Dokument [7] in einer unauthori- zed Nachricht an den Benutzer gesendet.
Im linken Bereich der Figur 4 ist durch einen grauen Bereich die Luftschnittstelle zwischen dem Endgerät UE und dem -CSCF-Server des GPRS-Netzes angedeutet. Die Datenübertragung über die Luftschnittstelle ist mit bekannten Mechanismen verschlüsselt. Folglich ist die Übertragung des Tokens an das Endgerät UE über die GPRS— uftschnittstelle geschützt. Im hier beschriebenen Ausführungsbeispiel wird der Token in einem HTTP-Digest-Header übertragen. Alternativ kann der Token auch in einem anderen Header oder Parameter übertragen werden, der unabhängig von dem HTTP-Digest-Header ist. Insbesondere kann der Token auch in einer separaten Nachricht übertragen werden.
Anschließend wird vom Benutzerendgerät UE über die Server P-CSCF und I-CSCF wiederum eine Register-Nachricht an den Rechner S-CSCF gesendet. Diese Register-Nachricht ist mit dem Sicherheitsprotokoll HTTP-Digest gesichert, wobei als gemeinsames Geheimnis zwischen dem Endgerät UE und dem Server S-CSCF der zuvor übertragene Token verwendet wird. Dies ist möglich, da der ToJten durch die Übertragung der vorangegangenen Register-Nachricht sowohl im Gerät UE als auch im S-CSCF bekannt ist. Schließlich erfolgt die Authentifizierung des Ξndgeräts UE im IMS-Netz, was in Figur 4 mit AU bezeichnet ist. Danach wird vom S-CSCF an das Gerät UE eine Bestätigung OK zurückgesandt . Im Anschluss kann der eigentliche Datenaus- tausch zwischen UE und IMS-Netz beginnen, wobei dieser Datenaustausch über HTTP-Digest gesichert ist. In Figur 4 ist beispielhaft eine Invite-Nachricht dargestellt, die im weiteren Datenaustausch gesendet wird.
In der hier eschriebenen Ausführungsform wird HTTP-Digest als Sicherheitsmechanismus für die IMS—Signalisierung verwendet. Statt HTTP-Digest könnten jedoch auch andere Sicherheitsmechanismen für die IMS-Signalisierung eingesetzt werden, sofern diese Sicherheitsmechanismen dynamische Schlüssel bzw. Passwörter verwenden. Ein weiteres Beispiel eines solchen Sicherheitsmechanismus ist der Mechanismus CMS (CMS = Cryptographic Message Syntax) .
Das erfindungsgemäße Verfahren kann insbesondere auch zur Si- cherung von HTTP—basierter Kommunikation zu ApplikationsServern verwendet werden. Es wird davon ausgegangen, dass der Benutzer aktuell an einem IMS-Netz angemeldet ist oder zumindest angemeldet war und über einen gültigen Token verfügt, der vom IMS-Netz akzeptiert wurde. Wenn nun ein Benutzer über das Endgerät UE mit einem HTTP-basierten Applikationsserver, der mit dem IMS-Netz verbunden ist, kommuniziert, kann HTTP- Digest zur Sicherung der HTTP— achrichten eingesetzt werden, wobei als Passwort für HTTP-Digest der Token verwendet wird. Damit der HTTP-Server in der Lage ist, die durch HTTP-Digest geschützte Nachricht zu prüfen, benötigt er ebenfalls diesen Token. Dieser wird dazu entweder vom S-CSCF oder vom HSS des IMS-Netzes an den Applikationsserver gesendet. Entsprechende Schnittstellen hierfür sind bekannt. Somit kann sowohl für die SIP-Signalisierung als auch für die HTTP-Signalisierung für Antworten aus dem IMS-Netz bzw. von einem HTTP-
Applikationss erver eine Sicherung über HTTP-Digest durchgeführt werden. Zusätzlich ist es möglich, für HTTP-Digest die Client- und Server— ollen zu tauschen. Üblicherweise werden die Nachrichten geschützt, die von dem Benutzerendgerät UE als Client ge- sendet werden. Für die Antworten des Netzes, das als Server agiert, werden die Nachrichten nur optional geschützt. Bei der Signalisierung mittels SIP kommt es jedoch vor, dass das Endgerät UE die Serverrolle und das Netz die Clientrolle ü- bernimmt . In diesem Fall kann HTTP-Digest entsprechend in u - gekehrter Richtung eingesetzt werden, so dass beispielsweise das Endgerät UE eine unauthorized Nachricht an den S-CSCF im IMS-Netz sendet.
Literaturverzeichnis :
[1] 3GPP SA3 (Security) (2002-09) : "Access security for IP-based Services (Release 5)", Technical speci ication 33.203 v5.3.0
[2] Siemens Paper on the IMS 2.0 early-start soluti- on : "early-start—ims—paper-final . zip"
[3] http://www.3gpp.org/ftp/tsg_sa/WG3_Security/ TSGS3_30_Povoa/Docs/ZIP/S3-030551. zip
[4] Ericsson, Motorola, Siemens, Nokia: "Push-To- Talk over Cellular (PoC) ; Signaling Flows; PoC Release 1.0", V 1.1.3, 8/2003.
[5] Ericsson, Motorola, Siemens, Nokia: "Push-To- Talk over Cellular (PoC) ; List management and do-not-disturb; PoC Release 1.0", V 1.1.3, 8/2003.
[6] Ericsson, Motorola, Siemens, Nokia: "Push-To- Talk over Cellular (PoC) ; Architecture; PoC Release 1.0", V 1.1.0, 8/2003.
[7] Siemens Presentation at Eurescom 2003: early- ims—slides-final—2003-09-17 (petri) .ppt
[8] 3GPP SA3 (Security) (2002-09) : "Network domain security; IP network layer security (Release 5)", Technical specification 33.210 v5.3.0

Claims

Patentansprüche
1. Verfahren zur Benutzerauthentifizierung und Sicherung des Datenverkehrs zwischen einem Mobilfunknetz (3) und einem IMS-Netz (4) :
- bei dem sich ein mobiler Teilnehmer (UE) im Mobilfunknetz (3) authentifiziert; bei dem sich der mobile Teilnehmer (UE) im IMS-Netz (4) authenti iziert ; - bei dem überprüft wird, ob die Identität des im IMS-Netz (4) authentifizierten mobilen Teilnehmers (UE) mit der Identität des im Mobilfunknetz (3) authentifizierten Teilnehmers (UE) übereinstimmt; bei dem im Falle übereinstimmender Identitäten eine Bestä- tigungsnachricht von dem IMS-Netz (4) an den mobilen Teilnehmer (UE) gesendet wird; bei dem ein Datenaustausch zwischen dem mobilen Teilnehmer (UE) und dem IMS-Netz (4) über ein durch einen gemeinsamen Schlüssel geschütztes Sicherheitsprotokoll erfolgt, wobei der Schlüssel für das Sicherheitsprotokoll aus der Bestätigungsnachricht abgeleitet wird.
2. Verfahren nach Anspruch 1, bei dem der Schlüssel die Bestätigungsnachricht ist.
3. Verfahren nach Anspruch 1 oder 2, bei dem der Schüssel ein gemeinsames Geheimnis zwischen dem IMS-Netz (4) und dem mobilen Teilnehmer (UE) ist.
4. Verfahren nach Anspruch 1 oder 2, bei dem der Schlüssel ein von dem mobilen Teilnehmer (UE) eingebbares Passwort ist .
5. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Bestätigungsnachricht ein Zufallswert ist.
6. Ver ahren nach einem der vorhergehenden Ansprüche, bei dem sich der mobile Teilnehmer (UE) im IMS-Netz (4) über das SIP-Protokoll (SIP = Session Initiation Protocol) und/oder HTTP-Protokoll authentifiziert .
7. Verfahren nach einem der vorhergehenden Ansprüche, bei dem das Sicherheitsprotokoll HTTP-Digest ist.
8. Datennetz, umfassend ein Mobilfunknetz und ein IMS-Netz, wobei das Datennetz derart ausgestaltet ist, dass der Datenverkehr zwischen einem mobilen Teilnehmer des Mobil— funknetzes (3) und dem IMS-Netz (4) gemäß einem Verfahren nach einem der vorhergehenden Ansprüche gesichert ist .
9. Datennetz nach Anspruch 8, bei dem das Mobilfunknetz (3) ein GPRS- und/oder UMTS-Netz ist.
PCT/EP2004/052527 2003-10-14 2004-10-13 Verfaren zur sicherung des datenverkehrs zwischen einem mobilfunknetz und einem ims-netz WO2005039141A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP04791217.5A EP1673921B1 (de) 2003-10-14 2004-10-13 Verfahren zur sicherung des datenverkehrs zwischen einem mobilfunknetz und einem ims-netz
US10/575,884 US7466976B2 (en) 2003-10-14 2004-10-13 Method for securing data traffic between mobile radio network and IMS network
JP2006534758A JP4384177B2 (ja) 2003-10-14 2004-10-13 移動無線網とｉｍｓネットワークとの間のデータトラフィックを保護する方法

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
DE10347772.1 2003-10-14
DE10347772 2003-10-14
DE10356091A DE10356091A1 (de) 2003-10-14 2003-12-01 Verfahren zur Sicherung des Datenverkehrs zwischen einem Mobilfunknetz und einem IMS-Netz
DE10356091.2 2003-12-01

Publications (1)

Publication Number Publication Date
WO2005039141A1 true WO2005039141A1 (de) 2005-04-28

Family

ID=34466017

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/052527 WO2005039141A1 (de) 2003-10-14 2004-10-13 Verfaren zur sicherung des datenverkehrs zwischen einem mobilfunknetz und einem ims-netz

Country Status (5)

Country Link
US (1) US7466976B2 (de)
EP (1) EP1673921B1 (de)
JP (1) JP4384177B2 (de)
RU (1) RU2328082C2 (de)
WO (1) WO2005039141A1 (de)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007003140A1 (fr) 2005-07-05 2007-01-11 Huawei Technologies Co., Ltd. Procede d'authentification de sous-systeme multimedia sous protocole ip
WO2007131548A1 (en) * 2006-05-15 2007-11-22 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatuses for establishing a secure channel between a user terminal and a sip server
CN100369430C (zh) * 2005-06-21 2008-02-13 中兴通讯股份有限公司 一种ip多媒体子系统接入安全的保护方法
WO2008037670A1 (de) * 2006-09-28 2008-04-03 Siemens Aktiengesellschaft Verfahren zum bereitstellen eines symmetrischen schlüssels zum sichern eines schlüssel-management-protokolls
CN101729528B (zh) * 2009-05-21 2012-11-28 中兴通讯股份有限公司 Ims会议电话的媒体安全实现方法和系统

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8307094B2 (en) * 2007-07-20 2012-11-06 Alcatel Lucent Method for processing register request, network element, and communication system
JP5034918B2 (ja) 2007-12-11 2012-09-26 日本電気株式会社 Ｉｍｓネットワークにおけるガイダンス確認装置および方法
US20100199341A1 (en) * 2009-02-02 2010-08-05 Telefonaktiebolaget Lm Ericsson (Publ) Methods, Subscriber Server, and User Equipment for Facilitating Service Provision
US8078870B2 (en) * 2009-05-14 2011-12-13 Microsoft Corporation HTTP-based authentication
JP5693575B2 (ja) * 2009-07-14 2015-04-01 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 電話番号の検証のための方法および装置
US8468343B2 (en) * 2010-01-13 2013-06-18 Futurewei Technologies, Inc. System and method for securing wireless transmissions
US8631090B2 (en) * 2011-08-04 2014-01-14 International Business Machines Corporation Resource-conserving technique for as-available data delivery to a mobile device
CN102726079B (zh) * 2011-12-06 2014-07-30 华为技术有限公司 移动终端的防盗方法及装置
KR101891639B1 (ko) * 2014-01-13 2018-08-24 노키아 솔루션스 앤드 네트웍스 오와이 웹 실시간 통신(WebRTC)에 있어 IP 멀티미디어 서브시스템(IMS)으로의 액세스에 대한 보안
KR102172468B1 (ko) * 2014-03-14 2020-10-30 삼성전자 주식회사 WebRTC서비스를 위해 단말이 브라우저를 통해 IMS망에 접속하기 위한 방법

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030159067A1 (en) * 2002-02-21 2003-08-21 Nokia Corporation Method and apparatus for granting access by a portable phone to multimedia services

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020007411A1 (en) * 1998-08-10 2002-01-17 Shvat Shaked Automatic network user identification
US6608832B2 (en) * 1997-09-25 2003-08-19 Telefonaktiebolaget Lm Ericsson Common access between a mobile communications network and an external network with selectable packet-switched and circuit-switched and circuit-switched services
FI980291A (fi) * 1998-02-09 1999-08-10 Nokia Mobile Phones Ltd Liikkuva internetpääsy
JP2001224070A (ja) * 2000-02-09 2001-08-17 Fujitsu Ltd モバイル通信システム及びその方法
US6925297B2 (en) * 2000-09-19 2005-08-02 Nortel Networks, Limited Use of AAA protocols for authentication of physical devices in IP networks
JP2003006168A (ja) * 2001-06-25 2003-01-10 Ntt Docomo Inc 移動端末認証方法及び移動端末
FI114276B (fi) * 2002-01-11 2004-09-15 Nokia Corp Verkkovierailun järjestäminen
US8195940B2 (en) * 2002-04-05 2012-06-05 Qualcomm Incorporated Key updates in a mobile wireless system
DE10223248A1 (de) 2002-05-22 2003-12-04 Siemens Ag Verfahren zum Registrieren eines Kommunikationsendgeräts
US7930412B2 (en) * 2003-09-30 2011-04-19 Bce Inc. System and method for secure access

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030159067A1 (en) * 2002-02-21 2003-08-21 Nokia Corporation Method and apparatus for granting access by a portable phone to multimedia services

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100369430C (zh) * 2005-06-21 2008-02-13 中兴通讯股份有限公司 一种ip多媒体子系统接入安全的保护方法
WO2007003140A1 (fr) 2005-07-05 2007-01-11 Huawei Technologies Co., Ltd. Procede d'authentification de sous-systeme multimedia sous protocole ip
EP1853032A1 (de) * 2005-07-05 2007-11-07 Huawei Technologies Co., Ltd. Verfahren zur authentifizierung eines ims
EP1853032A4 (de) * 2005-07-05 2008-06-25 Huawei Tech Co Ltd Verfahren zur authentifizierung eines ims
US7974604B2 (en) 2005-07-05 2011-07-05 Huawei Technologies Co., Ltd. Method of authentication in IP multimedia subsystem
US8364121B2 (en) 2005-07-05 2013-01-29 Huawei Technologies Co., Ltd. Method of authentication in IP multimedia subsystem
WO2007131548A1 (en) * 2006-05-15 2007-11-22 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatuses for establishing a secure channel between a user terminal and a sip server
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
WO2008037670A1 (de) * 2006-09-28 2008-04-03 Siemens Aktiengesellschaft Verfahren zum bereitstellen eines symmetrischen schlüssels zum sichern eines schlüssel-management-protokolls
DE102006046017B4 (de) * 2006-09-28 2010-01-14 Siemens Ag Verfahren zum Bereitstellen eines symmetrischen Schlüssels zum Sichern eines Schlüssel-Management-Protokolls
US8488795B2 (en) 2006-09-28 2013-07-16 Siemens Aktiengesellschaft Method for providing a symmetric key for protecting a key management protocol
CN101729528B (zh) * 2009-05-21 2012-11-28 中兴通讯股份有限公司 Ims会议电话的媒体安全实现方法和系统

Also Published As

Publication number Publication date
US20070140493A1 (en) 2007-06-21
RU2328082C2 (ru) 2008-06-27
JP2007515854A (ja) 2007-06-14
EP1673921B1 (de) 2018-11-28
JP4384177B2 (ja) 2009-12-16
EP1673921A1 (de) 2006-06-28
RU2006116515A (ru) 2007-11-27
US7466976B2 (en) 2008-12-16

Similar Documents

Publication Publication Date Title
EP1365620B1 (de) Verfahren zum Registrieren eines Kommunikationsendgeräts in einem Dienstnetz (IMS)
DE10307403B4 (de) Verfahren zum Bilden und Verteilen kryptographischer Schlüssel in einem Mobilfunksystem und Mobilfunksystem
EP1673921B1 (de) Verfahren zur sicherung des datenverkehrs zwischen einem mobilfunknetz und einem ims-netz
DE602004003518T2 (de) Verfahren und System zum legalen Abfangen von Paketvermittlungsnetzwerkdiensten
EP1943856B1 (de) Verfahren und server zum bereitstellen eines mobilitätsschlüssels
DE102006008745A1 (de) Verfahren und Server zum Bereitstellen eines Mobilitätsschlüssels
DE60206634T2 (de) Verfahren und System zur Authentifizierung von Benutzern in einem Telekommunikationssystem
DE60201522T2 (de) Ermöglichen legales abfangen von ip-verbindungen
WO2007051793A1 (de) Teilnehmerspezifisches erzwingen von proxy-mobile-ip (pmip) anstelle von client-mobile-ip (cmip)
EP2014010B1 (de) Verfahren, vorrichtungen und computerprogrammprodukt zum ver- und entschlüsseln von mediendaten
DE102006006071A1 (de) Verfahren zum Übertragen von Mediendaten, Netzwerkanordnung mit Computerprogrammprodukt
DE602004008293T2 (de) Transparente Zugangsauthentifikation in GPRS-Kern-Netzwerken
EP1982495A1 (de) Verfahren zum sichern der authentizität von nachrichten, die gemäss einem mobile internet protokoll ausgetauscht werden
EP1597861B1 (de) Verfahren zur übertragung von daten in einem wlan-netz
DE102006046017B4 (de) Verfahren zum Bereitstellen eines symmetrischen Schlüssels zum Sichern eines Schlüssel-Management-Protokolls
DE10238928B4 (de) Verfahren zur Authentifizierung eines Nutzers eines Kommunikationsendgerätes bei Nutzung eines Dienstnetzes
DE102006054091B4 (de) Bootstrapping-Verfahren
DE10356091A1 (de) Verfahren zur Sicherung des Datenverkehrs zwischen einem Mobilfunknetz und einem IMS-Netz
WO2006079298A1 (de) Mobilfunknetz, verfahren zum betreiben eines endgerätes in einem solchen und endgerät mit integrierten elektronischen schaltungsanordnungen zur speicherung von das endgerät identifizierenden parametern
EP4199550B1 (de) Verfahren zum übermitteln eines nachrichteninhalts in verschlüsselter form zwischen einem ersten kommunikationsteilnehmer und wenigstens einem zweiten kommunikationsteilnehmer, system, telekommunikationsnetz, computerprogramm und computerlesbares medium
DE102004032923B4 (de) Verfahren zum Registrieren eines Kommunikationsendgeräts, Kommunikationssystem, Verfahren zum Steuern eines Kommunikationsendgeräts und Kommunikationsendgerät
WO2004019641A1 (de) Verfahren zum authentifizieren eines nutzers eines kommunikationsendgeräts beim registrieren in einem und bei nutzung von einem dienstnetz
DE102006043340A1 (de) Verfahren und Vorrichtung zum Zuweisen eines Parameters in einer GBA-Bootstrapping-Prozedur
EP4203387A1 (de) Verfahren und system zur authentifizierung eines endgeräts eines nutzers
WO2008074620A2 (de) Verfahren und server zum bereitstellen eines zweckgebundenen schlüssels

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200480030298.5

Country of ref document: CN

AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2004791217

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2006534758

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 2007140493

Country of ref document: US

Ref document number: 10575884

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2006116515

Country of ref document: RU

WWP Wipo information: published in national office

Ref document number: 2004791217

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 10575884

Country of ref document: US