WO2007113073A1 - Verfahren zum wiederherstellen einer mit ipsec kryptographisch gesicherten verbindung zwischen p-cscf und anwendereinheit - Google Patents

Verfahren zum wiederherstellen einer mit ipsec kryptographisch gesicherten verbindung zwischen p-cscf und anwendereinheit Download PDF

Info

Publication number
WO2007113073A1
WO2007113073A1 PCT/EP2007/052164 EP2007052164W WO2007113073A1 WO 2007113073 A1 WO2007113073 A1 WO 2007113073A1 EP 2007052164 W EP2007052164 W EP 2007052164W WO 2007113073 A1 WO2007113073 A1 WO 2007113073A1
Authority
WO
WIPO (PCT)
Prior art keywords
cscf
proxy server
inbound
security
spi
Prior art date
Application number
PCT/EP2007/052164
Other languages
English (en)
French (fr)
Inventor
Li Cai
Joachim Kross
Michael Schopp
Original Assignee
Nokia Siemens Networks Gmbh & Co. Kg
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 Nokia Siemens Networks Gmbh & Co. Kg filed Critical Nokia Siemens Networks Gmbh & Co. Kg
Publication of WO2007113073A1 publication Critical patent/WO2007113073A1/de

Links

Classifications

    • 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
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/164—Implementing security features at a particular protocol layer at the network layer
    • 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/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection

Definitions

  • the invention relates to a method for restoring a cryptographically secured with IPsec connection between two IPsec peers.
  • This can be in the mobile area between a proxy-CSCF (Proxy-Call Session Control Function) server and to a serving CSCF (S-CSCF) registered user unit (UE) after a first proxy server (P-CSCF 1) in a visited by the user unit (UE) network (VN) was set up before the failure to mediate between the proxy server cluster node (P-CSCF 1) and the user unit (UE) sent messages.
  • the invention relates to the general topic for restoring a cryptographically secured connection with IPsec, in particular the security in the transmission of messages in the multimedia mobile radio area.
  • Mobile transmission systems are currently being standardized by the 3GPP (third generation partnership project). From the previous system of the second generation, the GSM (global system for mobile communications), a system of the third generation has developed, taking into account security aspects in particular, which is known in Europe under the name UMTS (universal mobile telecommunication system).
  • 3GPP third generation partnership project
  • the security aspects concern both the vulnerable transmission in the easily accessible radio frequency range between user unit (UE) and the access point (AN) as well as the infrastructure for the signal transmission in the core network (access point to the server of the Home network to which the user unit is assigned).
  • the third-generation security architecture of mobile systems is specified by the 3GPP inter alia in "3GPP TS 33.102".
  • 3GPP TS 33.102 3GPP TS 33.102
  • IMS IP multimedia core network subsystem
  • IP IP multimedia core network subsystem
  • IP IP multimedia core network subsystem
  • IP IP connectivity
  • known solutions are already being adopted for mobile communication from computer-based network architectures.
  • the session initiation protocol (IETF RFC 3261) SIP developed by the Internet Engineering Task Force (IETF), is intended as the protocol for setting up such sessions.
  • IMS-AKA IMS authentication and key agreement
  • the security architecture is specified by the 3GPP in "3GPP TS 33.203.”
  • the basic assumption with IMS-AKA is that security mechanisms are implemented not in the underlying IP transport layer but in the application layer. wireless local area network) standard IEEE 802.11 a certain independence of these mechanisms of network architectures of respective access points (AN) and thus of the realization of the transport layer is to be achieved.
  • a user unit includes an IP Services Identity Module (ISIM) that represents a collection of security functions and data.
  • the identity module supports the authentication with respect to a subscription server (HSS, home subscriber service) of the home network (HN) of the user unit.
  • the identity module includes, among others, a (unique and private) IMS identity (IMPI), the home network domain name (HN), support for checking sequence numbers, and keys for authentication that it shares with the subscription server ( symmetric encryption due to the generally low bandwidth in the transmission free space).
  • the user unit comprises a user agent (UA) which performs functions in accordance with the SIP protocol and communicates with a proxy server (P-CSCF, proxy-call session service function).
  • P-CSCF proxy-call session service function
  • the proxy server supports the SIP protocol and is assigned to the mobile application unit as soon as it connects to the access point (AN).
  • AN access point
  • PS domain packet switch domain
  • the proxy server is located in a network visited by the user unit (VN, visited network), which may possibly just be the home network (HN).
  • the proxy server initially communicates with a query server (I-CSCF) and then with the actual SIP server (S-CSCF, serving CSCF) of the home network (HN), the latter also as a server network (SN, serving network ) designated.
  • I-CSCF query server
  • S-CSCF serving CSCF
  • SN serving network
  • the server (S-CSCF) of the home network is connected to the subscription server (HSS), from which it receives authentication data in accordance with the SIP protocol on request.
  • the subscription server (HSS) also holds subscription information (e.g., authorizing the user to use the services at all).
  • FIG. 1 shows, by means of the lined arrows, those connections which must satisfy the security requirements against attacks by third parties.
  • SA security agreements
  • security associations are required, which have to be negotiated between the communication partners. Among other things, these regulate which key, which algorithm and which IP addresses and ports are used for the protected communication.
  • IMPU public identity
  • IMS public identity a selected user profile among many, which which can be associated with exactly one private identity (IMPI) and is part of the Identity Module (ISIM).
  • IMS-AKA Identity Module
  • the procedure is according to the SIP protocol and (based on this) the IMS-AKA protocol, whereby the registration / authentication is regulated in a challenge-response procedure.
  • the used symmetric keys are obtained from corresponding private secrets (eg in the manner of a Diffie-Hellmann key generation).
  • SA security agreements
  • UE user unit
  • P-CSCF proxy server
  • proxy server is equipped in cluster configuration.
  • a proxy server can e.g. consist of two cluster nodes and operate in a "hot" standby mode, a first cluster node is in an active state with the other cluster node in a standby state, if the active cluster node fails, the standby cluster becomes node
  • proxy server will be understood to mean only one cluster node at a time, if cluster configuration is present.
  • a proxy server or possibly its cluster node fails in particular during a running session between two communication partners.
  • a standby proxy server or a corresponding cluster node is available for such events.
  • this does not have the security agreements for the current sessions. He will therefore not be able to take over the ongoing connections or sessions without further ado.
  • the result is that the connections must be interrupted.
  • the connections can only be recreated if the user unit (UE) has re-registered in the network and the security agreement has been renegotiated. Namely, re-registering with renegotiated security agreements (SA) would result in the selection of a new server port on the user device side, however, the still running connection still addresses the old server port, as seen by the mobile user (UE).
  • SA re-registering with renegotiated security agreements
  • a particular problem is that the user unit (UE), so about a user of a mobile phone, etc., the
  • Proxy server can not send SIP messages to the user unit, it is up to 2 hours.
  • a currently defaulted first proxy server is replaced by a second standby proxy server, which takes over its position in the IMS and stores the security-relevant data of the users layer are replicated from the first proxy server.
  • the first (and also the second) proxy server have a computer architecture in which data of the application layer eg loaded in a main memory.
  • data of the application layer eg loaded in a main memory.
  • copies of data of the last available situation are created in the main memory, by means of which, for example, diagnoses can be carried out.
  • the copy data can be restored to secondary computers for review.
  • the regular security agreements of the failed proxy server are re-instantiated, ie used for communication with the user unit.
  • P-CSCF 1 failed proxy server
  • the sequence number is primarily used to protect against replay attacks. With each message exchange, the sequence number Counted by a date so that the simple recording and later playback can be detected by a listening attacker due to a repeated sequence number.
  • the sequence number is part of the transport layer in the IPsec structure.
  • An embodiment of this aspect therefore provides, when restoring an outbound security agreement (outbound SA: controls security regarding messages from the proxy server and the user unit) to set up a sufficiently large sequence number not equal to zero, which is sent with outgoing messages. It can be an arbitrarily large number.
  • the user unit UE compares the incoming sequence number with its counter reading and discards the message if the incoming sequence number has already been used.
  • sequence number of the application programming interface (API), which governs the relations between the operating system and the application on the proxy server can be set in this case.
  • the proxy server may select a maximum representable number, or it analyzes the replicated application layer for data representing a measure of the sequence number and adds a fixed value thereto. For example, the proxy server may determine the number of messages transmitted in the past or determine the number of bytes sent. A correspondingly prepared table converts these values into a sequence number that is likely to be valid at the time of the failure. It is important that the value of the sequence number is set higher than the actually existing, but lost value.
  • a further alternative for generating a matched sequence number according to this first aspect is to continuously from the standby proxy server (P-CSCF 2) from the originally active proxy server (P-CSCF 1) regularly before the failure. monitor and retrieve the current sequence number.
  • inbound SA inbound regular security agreement
  • UE user unit
  • This embodiment therefore envisages only registering messages (REGISTER messages) in accordance with the SIP protocol as part of the re-instantiation or restoration of these regular inbound SAs.
  • a limit can be set for the number of messages or bytes that are exceeded if the inbound SA and thus the connection are deleted.
  • security agreements are considered to be regular if they comply with the standard set of agreements specified in 3GPP TS 33.203 (for example, current version 7.0.0 ReI.
  • 3GPP TS 33.203 for example, current version 7.0.0 ReI.
  • P-CSCF proxy server
  • a further embodiment therefore provides that the reinstanz elected SAs only temporarily use until newly established, also posted for replay attacks secured security agreements both by the user unit (UE) and on the part of the proxy server (P-CSCF 2).
  • One idea is to send a request (also referred to below as recovery request or abbreviated to "RR") for the purpose of restoring the connection from the proxy server (P-CSCF 2) to the user unit (UE).
  • a request also referred to below as recovery request or abbreviated to "RR”
  • RR recovery request
  • the request (RR) is protected by the parameters according to the temporary, outbound SA of the proxy server (P-CSCF 2).
  • the transmission of the request (RR) to the UE occurs e.g. including the calculated or fixed sequence number.
  • Network-Initiated Re-Registration (translated with network-initiated re-registration), which is triggered by the serving CSCF (S-CSCF)
  • S-CSCF serving CSCF
  • RR request
  • UE user unit
  • S-CSCF serving CSCF
  • the construction of new, secured SAs on both sides is carried out on the basis of a special handshake. stelligt.
  • the starting point is already a fixed inbound SA as well as a still temporary outbound SA at the proxy server (P-CSCF 2).
  • the user unit (UE) becomes the same outbound SA was deleted. Furthermore, a corresponding new inbound SA and a new outbound SA are set up, which are compatible with the recovered SAs of the second proxy server (P-CSCF 2). Old and new inbound SA coexist temporarily on the user unit (UE) side. They can be distinguished according to the IPsec specification (RFC 2401) by their different SPI indices. The SPI indices are used for the mutual selection and referencing of security agreements between the communication partners.
  • the user unit (UE) then sends a response (Response to RR) to the proxy server (P-CSCF 2) with its corresponding SPI indexes.
  • the proxy server (P-CSCF 2) can adapt its outbound security agreement (outbound SA), i. renew.
  • outbound SA outbound security agreement
  • the old outbound SA by means of which the recovery request (RR) was protected, is now deleted and a new outbound SA is set up by the proxy server (P-CSCF 2) with that of the user unit transmitted SPI indexes is compatible.
  • the proxy server acknowledges receipt of the response to the user unit (UE) so that the latter can now also delete its old inbound SA.
  • a second embodiment of the inventive concept with respect to the Recovery Request (RR) is to perform a partially unprotected re-registration after sending the request, which is protected by the proxy server (P-CSCF 2) as stated above based on the restored outbound SA ,
  • the user unit (UE) responds to the request with a REGISTER request according to the SIP protocol.
  • a re-registration is generally used to switch to new security agreements during a session.
  • the re-registration differs from the initial registration in that it is authenticated.
  • normally protected ports are used, with each protected server port even being preserved when switching from old to new security agreements.
  • the conventional registration is in the standard 3GPP TS 33.203 in chapter 6.1.1, the setup of SAs in chapter 7.2. and the re-registration in chapter 7.4. specified.
  • the REGISTER request directed to the destination server S-CSCF is first sent to an unprotected server port of the proxy server (P-CSCF 2) in accordance with the SIP protocol via an unprotected client port of the user unit (UE).
  • the response from the proxy server (P-CSCF 2) has, as part of the IMS-AKA protocol for authentication, a challenge value created by the server (S-CSCF) of the home network (see 3GPP TS 33.203, Chapter 6.1.1).
  • the difference to the valid re-registration is therefore the use of unprotected ports as well as an authentication, which is similar to the initial registration.
  • the proxy server marks this as unprotected before forwarding the REGISTER request to the server (S-CSCF).
  • the home network server recognizes with respect to the REGISTER request that it is part of a re-registration in a running connection. He recognizes this, for example, that some of the registration states remain unchanged, or that the proxy server (P-CSCF) tells him the authentication of the UE.
  • the destination server S-CSCF performs a re-enrollment whenever the proxy server notifies it that it is a protected REGISTER message. Nevertheless, the server (S-CSCF) recognizes that the request is marked as unprotected.
  • the decisive factor is that the serving CSCF (S-CSCF) can easily identify which steps are to be carried out based on a marking of the message by the proxy server (P-CSCF 2).
  • the home network server treats the REGISTER request as part of a re-registration procedure and not an initial registration because this would mean aborting the previous SIP session. Nevertheless, the server (S-CSCF) performs a new mandatory authentication, which is conventionally only performed optionally during the re-registration.
  • SA security agreements between user unit (UE) and proxy server (P-CSCF 2) are renegotiated in the re-registration proposed here.
  • P-CSCF 2 proxy server
  • a second aspect of the invention unlike the first aspect, does not continue to use the old, regular, recovered security agreements (SAs) for the purpose of encryption, but rather to provide dedicated fail-over SAs. These serve only for the restoration of the current connection after failure of the primary proxy server (P-CSCF 1).
  • SAs recovered security agreements
  • P-CSCF 1 primary proxy server
  • a particular advantage offered by such from the regular SAs are separate failover SAs that, in the absence of use of these fail-over SAs prior to a failure, the sequence number for dispatched messages is agreed in an agreed manner on both sides ( UE and P-CSCF 2) is at a fixed value, for example zero.
  • the fail-over SAs are used to encrypt and secure the Recovery Request (RR).
  • RR Recovery Request
  • the fail-over SA On the side of the user unit (UE), the fail-over SA is held permanently until the failure of the communication partner occurs.
  • the fail-over SA is used and consumed. That is, it is deleted after use and replaced with a new fail-over SA negotiated with the proxy server (P-CSCF 2).
  • the information is held only in the application layer in the first proxy server (P-CSCF 1), that is, it finds no permanent Building a fail-over SA instead. It can not and should not be used during a connection that has not yet failed.
  • P-CSCF 2 Only after the failure and the replication of the security information on the second and previous standby proxy server (P-CSCF 2) is a dedicated fail-over SA set up from this information of the application layer.
  • the difference between simply holding the fail-over SA information in the application layer and an explicit establishment of the fail-over SA after the failure consists in the storage in a separate safety database in which SAs are externally referenced using SPI. Pointers can be addressed.
  • a third aspect of the invention relates to the triggering (triggering) of a customized re-registration as initially described in the first aspect, but without an encryption of the request or of the recovery request (RR) via security agreements - neither via regular nor via fail-over SAs - takes place.
  • An embodiment of the third aspect provides for setting up a separate, pre-coordinated secret based on shared-key material, with which the encryption of the trigger message (request RR) takes place.
  • a further embodiment of the third aspect provides that no further change in the status of the registration after restoration is permitted, ie. a ban on further re-registrations of the current session. This can be done, for example, by setting a flag on the proxy server side (P-CSCF 2) which identifies the current session and is deleted after the connection has ended.
  • P-CSCF 2 proxy server side
  • a further embodiment of the third aspect provides for limiting the number of admissible requests for restoring a session or connection within a defined period of time after the outage.
  • Figure 1 the basic structure of an IMS system according to 3GPP;
  • Figures 2-4 are flowcharts showing successive steps of a two-way handshake for recovering SAs of an ongoing connection between user unit (UE) and proxy server (P-CSCF 2) using pre-agreed fail-over SAs.
  • UE user unit
  • P-CSCF 2 proxy server
  • FIG. 1 shows the basic structure of an IMS system according to 3GPP, as it is described in this document initially.
  • the measures according to the embodiment to be described relate to a handshake, i. an exchange of information between the user unit (UE), more precisely: its user agent (UA), and the second proxy server (P-CSCF 2), after a failure of a first proxy server (P-CSCF 1) whose function the transfer of messages from and to the server (S-CSCF) takes over.
  • the SAs described below thus relate to the arrow representing the connection UA-P-CSCF in FIG. 1.
  • FIG. 2 shows a first part of a flowchart with which this handshake is to be explained.
  • the handshake is performed outside of a registration or re-registration and therefore runs outside currently established standards.
  • P-CSCF 1 Prior to the failure of the first proxy server (P-CSCF 1), there are pairs of regular inbound and outbound SAs on both sides (UE and P-CSCF 1). In addition, a fail-over SA was agreed, which is also deposited as such with the user unit (UE). The server-side information (security parameters) present in the fail-over SA is also in the application layer of the proxy server (P-CSCF 1), but without creating its own fail-over SA in the proxy server (P-CSCF 1).
  • the manner in which the fail-over SA is created can be seen from the further sequence according to FIGS. 2-4.
  • the old, regular SAs prior to the failure are created according to the state of the art as part of an initial registration in security mode (see 3GPP TS 33.203 (Chapter 7.2) and RFC 3329).
  • the safety parameters of the regular SAs include: so-called selectors, e.g. IP addresses (source and destination, linked to SIP flow), transport protocols (TCP or UDP, negotiated), protected port addresses (source and destination, linked to SIP flow), further algorithms (encryption and integrity), assigned SPI Pointer for inbound SAs, lifetime (in seconds, is negotiated), current and maximum sequence number (the latter is negotiated, eg 2 ⁇ 1 - 1), length of the key for integrity algorithm (negotiated, eg 128 bit for HMAC-MD5-96 or 160 bit for HMAC-SHA-1-96), length of the key for Encyption (negotiated, eg for DES-EDE3-CBC (RFC 2451) or AES-CBC (RFC 3602) with at least 128 bit).
  • selectors e.g. IP addresses (source and destination, linked to SIP flow), transport protocols (TCP or UDP, negotiated), protected port addresses (source and destination, linked to SIP flow), further algorithms (encryption and
  • the failure of the first proxy server (P-CSCF 1) is signaled to the second standby proxy server (P-CSCF 2). This immediately takes over the IP address of the first proxy server (P-CSCF 1).
  • P-CSCF 1 replicates the data of the application layer of the first proxy server (P-CSCF 1), in particular the security-related information of the regular SAs that existed prior to the failure.
  • the second proxy server (P-CSCF 2) will create new regular inbound SAs.
  • a fail-over SA is created.
  • the outbound failover SA of the proxy server (P-CSCF 2) for example, the following safety parameter required: own source and foreign destination port number of the user unit (UE), the SPI value assigned by the user unit (UE) of this fail-over SA.
  • the IP addresses are the same as for the regular SAs.
  • the protected (protected) server port of the UE is known by the replication of the application layer and is preferably chosen for the fail-over SA as a destination port.
  • the protected client port of the proxy server (P-CSCF 2) of this fail-over SA must then be selected for the sake of uniqueness other than that for the regular SAs.
  • the sequence number is zero.
  • the proxy server (P-CSCF 2) allocates new SPI indices (spi pc and spi-ps) for the regular inbound SAs (because of the selected UDP protocol, these are two instead of just one SA (TCP) the number) .
  • a request is generated and sent to the user unit (UE).
  • the message also conveys the SPI indexes (spi-pc and spi-ps).
  • the sequence number counts up by the use of the counter "1".
  • the Recovers request (RR) is received and permitted (decrypted, verified, authenticated, etc.) on the basis of the still existing old fail-over SA.
  • the received sequence numbers are greater than those present at the UE, because the inbound failover SA of the UE has not yet been used.
  • the old regular SAs are removed as they are no longer needed.
  • New inbound and outbound SAs are set up.
  • the former are assigned for this purpose allocated SPI indices (spi-uc and spi-us).
  • a new inbound fail-over SA is also set up and also assigned to an allocated SPI index (spi-f).
  • the SPI indices (spi-uc, spi-us and spi-f) are now encapsulated in a response to the request (recovery request) and protected (integrity and encryption) according to the agreements to which the index spi-ps shows.
  • the answer is sent to the proxy server (P-CSCF 2).
  • the message is sent from port port_uc of user unit UE via UDP to the port_ps of the proxy server (P-CSCF 2) (for the port designations see 3GPP TS 33.203 Version 7.0.0 Release 7, Page 21-23).
  • the proxy server (P-CSCF 2) in turn creates new regular outbound SAs based on the information obtained (SPI pointer). In addition, the initially created but now obsolete outbound failover SA of the proxy server (P-CSCF 2) is deleted. Now there are two parallel existing fail-over SAs (old and new) on the user unit side, and there is no longer a fail-over SA on the proxy server side (P-CSCF 2). By contrast, the proxy server (P-CSCF 2) has access to the security parameters of the UE's new fail-over SA on the basis of the information indicated by spi-f, whereby it only holds these parameters in the application layer.
  • the proxy server acknowledges receipt of spi-f to the user unit (UE). This is done on the basis of the new outbound SA and not the old failover SA, as far as the encryption is concerned. As a result, the user unit (UE) removes the old fail-over SA, so that only the new inbound fail-over SA remains.

Abstract

Ein Verfahren zum Wiederherstellen einer kryptographisch sicheren IPsec-Verbindung zwischen einem zweiten Proxy-Server (P-CSCF 2) und einer gegenüber einem Server (S-CSCF) registrierten Anwendereinheit (UE), nachdem ein erster Proxy-Server (P-CSCF 1) in einem von der Anwendereinheit (UE) besuchten Netzwerk (VN) ausgefallen ist, welcher vor dem Ausfall zur Vermittlung von zwischen dem Server (S-CSCF) und der Anwendereinheit (UE) versandten Nachrichten eingerichtet war, umfasst die Schritte: Bereitstellen des zweiten Proxy-Servers (P-CSCF 2) in dem besuchten Netzwerk (VN); Übernehmen einer IP-Adresse des ersten Proxy-Servers (P-CSCF 1) durch den zweiten Proxy-Server (P-CSCF 2), so dass dieser an die Stelle des ersten Proxy-Servers (P-CSCF 1) bezüglich der Vermittlung von Nachrichten tritt; Replizieren von Informationen betreffend die kryptographische Sicherheit der Verbindung in dem zweiten Proxy-Server (P-CSCF 2), welche zuletzt vor dem Ausfall in der Anwendungsschicht im ersten Proxy-Server (P-CSCF 1) gespeichert waren; und Verwenden der replizierten Informationen zur Erstellung wenigstens einer Sicherheitsvereinbarung (SA) zwischen dem zweiten Proxy-Server (P-CSCF 2) und der Anwendereinheit (UE) in dem Proxy-Server (P-CSCF 2), anhand welcher nachfolgend eine Verschlüsselung der vermittelten Nachrichten durchgeführt wird.

Description

Beschreibung
VERFAHREN ZUM WIEDERHERSTELLEN EINER MIT IPSEC KRYPTOGRAPHISCH GESICHERTEN VERBINDUNG ZWISCHEN P-CSCF UND ANWENDEREINHEIT
Die Erfindung betrifft ein Verfahren zum Wiederherstellen einer mit IPsec kryptographisch gesicherte Verbindung zwischen zwei IPsec peers . Das kann in Mobilfunkbereich zwischen einem Proxy-CSCF (Proxy-Call Session Control Function) Server und einer gegenüber einem Serving-CSCF (S-CSCF) registrierten Anwendereinheit (UE) , nachdem ein erster Proxy-Server (P-CSCF 1) in einem von der Anwendereinheit (UE) besuchten Netzwerk (VN) ausgefallen ist, welcher vor dem Ausfall zur Vermittlung von zwischen dem Proxy Server Cluster Node (P-CSCF 1) und der Anwendereinheit (UE) versandten Nachrichten eingerichtet war. Die Erfindung betrifft die allgemeine Thematik zum Wiederherstellen einer mit IPsec krytographisch gesicherte Verbindung, insbesondere die Sicherheit bei der Übertragung von Nachrichten im multimedialen Mobilfunkbereich.
Mobile Ubertragungssysteme werden derzeit durch die 3GPP (third generation partnership project) standardisiert. Aus dem bisherigen System zweiter Generation, dem GSM (global System for mobile Communications) , hat sich dabei unter Be- rucksichtigung vor allem von Sicherheitsaspekten ein System dritter Generation entwickelt, das in Europa unter dem Namen UMTS (universal mobile telecommunication System) bekannt ist.
Die Sicherheitsaspekte betreffen sowohl die angreifbare Uber- tragung im leicht zuganglichen Radiofrequenzbereich zwischen Anwendereinheit (UE, user equipment) und dem Zugangspunkt (AN, access network) , als auch die Infrastruktur für die Sig- nalubertragung im Core-Netzwerk (Zugangspunkt bis zum Server des Heimatnetzwerks, dem die Anwendereinheit zugeordnet ist) . Die Sicherheitsarchitektur mobiler Systeme der dritten Generation ist von der 3GPP unter anderem in „3GPP TS 33.102" spezifiziert . Gemäß dem UMTS-Standard besteht ferner die Möglichkeit, multimediale Verbindungen (sessions) zwischen den beteiligten Kommunikationspartnern aufzubauen. Durch das so genannte IMS (IP multimedia core network Subsystem) werden dabei von einer UMTS packet-domain Dienste für die IP-Konnektivitat angeboten (IP: internet protocol) . Es werden somit für die mobile Kommunikation bereits aus rechnerbasierten Netzwerkarchitekturen bekannte Losungen übernommen. Als Protokoll für den Aufbau solcher Sessions ist das SIP (session initiation protocol, IETF RFC 3261) vorgesehen, das von der Internet Engineering Task Force (IETF) entwickelt wurde.
Das für IMS verwendete Sicherheitsschema heißt IMS-AKA (IMS authentication and key agreement) . Die Sicherheitsarchitektur ist von der 3GPP in „3GPP TS 33.203" spezifiziert. Grundannahme bei IMS-AKA ist, dass Sicherheitsmechanismen nicht in der unterliegenden IP-Transportschicht sondern in der Anwendungsschicht realisiert werden. Der Grund liegt darin, dass z.B. im Hinblick auf den WLAN (wireless local area network) Standard IEEE 802.11 eine gewisse Unabhängigkeit dieser Mechanismen von Netzwerkarchitekturen jeweiliger Zugangspunkte (AN) und damit von der Realisierung der Transportschicht erreicht werden soll.
Die IMS-Architektur ist schematisch und beispielhaft in Figur 1 gezeigt. Eine Anwendereinheit (UE) umfasst ein IP-Services Indentitatsmodul (ISIM), das eine Zusammenstellung von Sicherheitsfunktionen und -daten repräsentiert. Das Identitats- modul unterstutzt unter anderem die Authentikation gegenüber einem Subskriptionsserver (HSS, home subscriber Service) des Heimatnetzwerks (HN) der Anwendereinheit. Das Identitatsmodul (ISIM) beinhaltet unter anderem eine (eindeutige und private) IMS-Identitat (IMPI), den Domain-Namen des Heimatnetzwerks (HN) , Unterstützung für die Überprüfung von Sequenznummern und Schlüssel für die Authentikation, den es mit dem Subskriptionsserver teilt (symmetrische Verschlüsselung aufgrund der im allgemeinen niedrigen Bandbreite bei der Übertragung freien Raum) . Ferner umfasst die Anwendereinheit (UE) einen User Agent (UA) , der Funktionen gemäß dem SIP-Protokoll ausführt und mit einem Proxy-Server (P-CSCF, proxy-call Session Service func- tion) kommuniziert. Der Proxy-Server unterstützt das SIP- Protokoll und wird der mobilen Anwendungseinheit zugewiesen, sobald sich dieses mit dem Zugangspunkt (AN, access network) verbindet. Auf Transportschichtebene findet die Kommunikation über die PS-Domain (packet switch domain) statt.
Der Proxy-Server (P-CSCF) liegt in einem von der Anwendereinheit besuchten Netzwerk (VN, visited network) , bei dem es sich unter Umständen auch gerade um das Heimatnetzwerk (HN, home network) handeln kann. Der Proxy-Server kommuniziert leitungsgebunden zunächst mit einem Abfrage-Server (I-CSCF) und dann mit dem eigentlichen SIP-Server (S-CSCF, serving CSCF) des Heimatnetzwerks (HN) , letzteres auch als Server- Netzwerk (SN, serving network) bezeichnet.
Der Server (S-CSCF) des Heimatnetzwerks ist mit dem Subskriptionsserver (HSS) verbunden, von dem er auf Anfrage Authenti- kationsdaten gemäß SIP-Protokoll erhält. Der Subskriptionsserver (HSS) hält ferner Subskriptionsinformationen (z.B. die Authorisierung des Anwenders, überhaupt die Dienste nutzen zu dürfen) .
Fig. 1 zeigt anhand der linierten Pfeile diejenigen Verbindungen, die den Sicherheitsanforderungen gegenüber Angriffen Dritter genügen müssen. Es sind jeweils sogenannte Sicher- heitsvereinbarungen (SA, security associations) erforderlich, die zwischen den Kommunikationspartnern auszuhandeln sind. In diesen ist unter anderem geregelt, welcher Schlüssel, welcher Algorithmus und welche IP-Adressen und Ports für die geschützte Kommunikation eingesetzt werden.
Der Zugang zu den Diensten des IMS erfolgt über die Registrierung einer öffentlichen Identität (IMPU, IMS public iden- tity) , einem ausgewählten Anwenderprofil unter vielen, welche der genau einen privaten Identität (IMPI) zugeordnet sein können, und Teil des Identitätsmoduls (ISIM) ist. Ferner muss die private Identität (IMPI) authentifiziert werden. Es wird dazu gemäß dem SIP-Protokoll und (darauf aufbauend) dem IMS- AKA Protokoll verfahren, wobei die Registrierung / Authenti- kation in einem Challenge-Response-Verfahren geregelt wird. Die verwendeten symmetrischen Schlüssel werden hier aus entsprechend jeweils privaten Geheimnissen erhalten (z.B. nach Art einer Diffie-Hellmann Schlüsselerzeugung) .
Die Sicherheitsvereinbarungen (SA) werden zwischen der Anwendereinheit (UE) und dem Proxy-Server (P-CSCF) im Rahmen einer solchen IMS-AKA-Authentikation ausgehandelt.
In Fig. 1 wird die Trennung zwischen der Transportschicht (unten) und der Anwendungsschicht (oben) deutlich.
In der Praxis, um die Verfuegbarkeit zu erhöhen, wird der Proxy-Server in Cluster-Konfiguration ausgestattet. Ein Pro- xy-Server kann z.B. aus zwei Cluster Nodes bestehen und in einem „Hot"-Standby Modus betrieben werden. Ein erster Cluster Node befindet in aktivem Betriebszustand, wobei sich der andere Cluster Node in Standby-Zustand befindet. Falls der aktive Cluster Node ausfällt, wird der Standby Cluster Node die Aufgabe übernehmen. Im folgenden wird unter dem Begriff Proxy-Server jeweils auch nur ein Cluster Node verstanden, wenn Clusterkonfiguration vorliegt.
Es kann nun das Problem auftreten, dass ein Proxy-Server oder ggf. dessen Cluster Node insbesondere während einer laufenden Session zwischen zwei Kommunikationspartnern ausfällt. Im allgemeinen steht für solche Ereignisse ein Standby-Proxy- Server bzw. ein entsprechender Cluster Node zur Verfügung. Jedoch verfügt dieser für die laufenden Sessions nicht über die Sicherheitsvereinbarungen. Er wird daher nicht ohne weiteres die laufenden Verbindungen bzw. Sessions übernehmen können. Die Folge ist, dass die Verbindungen unterbrochen werden müssen. Die Verbindungen können erst wieder neu aufge- baut werden, wenn die Anwendereinheit (UE) sich im Netz neu registriert und die Sicherheitsvereinbarung neu ausgehandelt worden sind. Eine Neuregistrierung mit neu ausgehandelten Sicherheitsvereinbarungen (SA) würde nämlich zur Auswahl eines neuen Server-Ports auf Seiten der Anwendereinheit führen, jedoch adressiert die noch laufende Verbindung von dem mobilen Anwender (UE) aus gesehen immer noch den alten Server-Port.
Besonders problematisch ist dabei, dass die Anwendereinheit (UE), also etwa ein Benutzer eines Mobiltelefons etc., den
Ausfall und damit den Abbruch der Verbindung nicht sofort erkennt. Gemäß 3GPP-Spezifiaktionen ist nämlich nicht vorgesehen, dass der Proxy-Server (P-CSCF) den mobilen Anwender über den Verlust der Sicherheitsvereinbarungen (SA) informiert. Die Zeitdauer für eine solche Unterbrechung, in denen der
Proxy-Server keine SIP-Meldungen an die Anwendereinheit senden kann, beträgt dabei bis zu 2 Stunden.
Es ist daher die Aufgabe, ein Verfahren zum Wiederherstellen einer Verbindung zwischen einem Server und einer Anwendereinheit bei einem Ausfalls eines vermittelnden Proxy-Server anzugeben, dass die vorgenannten Nachteile umgeht und eine Fortsetzung einer Verbindung ohne Verluste an Daten, Sicherheit und Zeit ermöglicht.
Die Aufgabe wird gelöst durch ein Verfahren nach Anspruch 1. Vorteilhafte Ausgestaltungen sind den abhängigen Ansprüchen zu entnehmen.
Es werden zur Lösung des Problems Vorgehensweisen vorgeschlagen, denen ein Grundgedanke gemeinsam ist: ein aktuell ausgefallener erster Proxy-Server wird durch einen zweiten Stand- by-Proxy-Server ersetzt, der dessen Position im IMS übernimmt, und auf dem die sicherheitsrelevanten Daten der Anwen- dungsschicht vom ersten Proxy-Server aus repliziert werden.
Der erste (und auch der zweite) Proxy-Server besitzen eine Rechnerarchitektur, bei welcher Daten der Anwendungsschicht z.B. in einem Hauptspeicher geladen sind. Üblicherweise werden im Fall von auftretenden Problemen Kopien von Daten der zuletzt vorliegenden Situation im Hauptspeicher geschaffen, anhand welcher zum Beispiel Diagnosen durchgeführt werden können. Die Kopiedaten können dabei auf Zweitrechnern zur Nachprüfung wiederhergestellt werden.
Diese Möglichkeit wird vorliegend ausgenutzt. Wie beschrieben befindet sich nämlich ein Großteil der Sicherheitsinformatio- nen (gemäß IPsec) in der Anwendungsschicht. Zunächst tritt der neue Proxy-server (P-CSCF 2) durch Übernahme der IP- Adresse an die Stelle des ausgefallenen Proxy-Servers (P-CSCF 1) . Als nächstes werden die Daten der Anwendungsschicht repliziert. Die ausgefallenen, aber früher ausgehan- delten Sicherheitsvereinbarungen werden - soweit möglich - wieder hergestellt. Dazu gehören insbesondere die gemeinsamen Schlüssel, Verschlusselungsalgorithmen, Port-, Quell- und Zieladressen .
Einem ersten Aspekt der Erfindung zufolge werden die regulären Sicherheitsvereinbarungen des ausgefallenen Proxy-Servers (P-CSCF 1) re-instantiiert, also für die Kommunikation mit der Anwendereinheit weiterverwendet. Ein Problem, das dabei auftritt und allen hier vorgestellten Aspekten zugrunde liegt, betrifft solche Sicherheitsparameter in den Sicherheitsvereinbarungen, die nicht aus der Anwendungsschicht repliziert werden können.
Die oben genannten Kopiedaten betreffen nämlich gerade aus- schließlich jene Daten der Anwendungsschicht. Die sich auf der Transport- oder Netzwerkebene abspielenden Prozesse im Moment des Ausfalls sind dagegen unwiederbringlich verloren. Das gilt somit auch für sicherheitsrelevante Daten wie insbesondere die Sequenznummer einer jeweiligen Sicherheitsverein- barung.
Die Sequenznummer dient vor allem dem Schutz vor Replay- Attacken. Mit jedem Nachrichtenaustausch wird die Sequenznum- mer um ein Datum hochgezählt, so dass die einfache Aufzeichnung und spätere Wiedergabe durch einen mitlauschenden Angreifer aufgrund einer wiederholten Sequenznummer erkannt werden kann. Die Sequenznummer ist Teil der Transportschicht im IPsec-Aufbau .
Eine Ausgestaltung dieses Aspekts sieht daher vor, beim Wiederherstellen einer auswärts gerichteten Sicherheitsvereinbarung (outbound SA: regelt Sicherheit bezüglich Nachrichten vom Proxy-Server and die Anwendereinheit) eine hinreichend große Sequenznummer ungleich Null einzurichten, die mit ausgehenden Nachrichten versandt wird. Es kann sich dabei um eine beliebig große Zahl handeln. Die Anwendereinheit (UE) vergleicht nämlich die eingehende Sequenznummer mit ihrem Zäh- lerstand und verwirft die Nachricht, wenn die bei ihr eingehende Sequenznummer schon einmal verwendet wurde.
Beispielsweise kann die Sequenznummer vom API (application Programming interface) , welche die Beziehungen zwischen Be- triebssystem und Anwendung auf dem Proxy-Server regelt, für diesen Fall festgesetzt werden.
Alternativ kann der Proxy-Server (P-CSCF 2) eine maximal darstellbare Zahl auswählen, oder er analysiert die replizierte Anwendungsschicht nach Daten, die ein Maß für die Sequenznummer darstellen und addiert einen festen Wert dazu. Zum Beispiel kann der Proxy-Server die Anzahl in der Vergangenheit übermittelter Nachrichten bestimmen oder die Anzahl gesendeter Bytes ermitteln. Eine entsprechend bereitgestellte Tabel- Ie rechnet diese Werte in eine voraussichtlich im Zeitpunkt des Ausfalls gültige Sequenznummer um. Wichtig ist, dass hier der Wert der Sequenznummer höher gesetzt ist als der tatsächlich vorhandene, aber verlorene Wert.
Eine weitere Alternative zur Erzeugung einer angepassten Sequenznummer gemäß diesem ersten Aspekt besteht darin, kontinuierlich vor dem Ausfall vom Standby-Proxy-Server (P-CSCF 2) aus den ursprünglich aktiven Proxy-Server (P-CSCF 1) regelmä- ßig zu überwachen und die jeweils aktuelle Sequenznummer abzufragen .
Für eine einwärts gerichtete reguläre Sicherheitsvereinbarung (inbound SA) des Proxy-Servers sind gleichfalls Ausgestaltungen des erfindungsgemaßen Verfahrens gemäß dem ersten Aspekt vorgesehen: es besteht hier nämlich ein Problem dahingehend, dass bei der Instantiierung dieser Sicherheitsvereinbarung das Empfangsfenster für IPsec Nachrichten bei Null startet. Das bedeutet, dass alle eingehenden Nachrichten von der Anwendereinheit (UE) diese Hürde leicht nehmen können, so dass auch potentielle Replay-Attacken erfolgreich sein können.
Diese Ausgestaltung sieht daher vor, im Rahmen der Re- Instantiierung bzw. Wiederherstellung dieser regulären Inbound SA lediglich Registriernachrichten (REGISTER-messages) gemäß SIP-Protokoll zuzulassen. Alternativ kann auch eine Grenze der Anzahl der Nachrichten oder Bytes gesetzt werden, bei deren Überschreitung der Inbound SA und damit die Verbin- düng geloscht wird. Durch diese Ausgestaltung gelingt zumindest eine Reduzierung der Angriffsmoglichkeiten .
Sicherheitsvereinbarungen werden vorliegend als regulär bezeichnet, wenn sie dem in 3GPP TS 33.203 (z.B. aktuelle Ver- sion 7.0.0 ReI. 7) insbesondere in Kapitel 7 spezifizierten Standardsatz von Vereinbarungen entsprechen. Grundsatzlich bestehen dabei auf jeder Seite, d.h. bei der Anwendereinheit (UE) und dem Proxy-Server (P-CSCF) jeweils eine inbound SA und eine outbound SA, zusammen also 4 Sicherheitsvereinbarun- gen.
Grundsatzlich besteht gemäß diesem ersten Aspekt nach Wiederherstellung der ausgefallenen Sicherheitsvereinbarungen die Möglichkeit, anhand dieser SAs die laufende Verbindung zwi- sehen Anwendereinheit (UE) und Proxy-Server (P-CSCF 2) in nachfolgenden Schritten des Nachrichtenaustauschs aufrecht zu erhalten. Wie oben ausgeführt ist jedoch der Grad an Sicherheit gegenüber Replay-Attacken in diesem Fall nur einge- schrankt vorhanden, weil die ursprunglich im ersten Proxy- Server (P-CSCF 1) bekannten Sequenznummern dem zweiten Proxy- Server (P-CSCF 2) unbekannt sind und dieser daher nur mit groben Abschatzungen rechnen kann.
Eine weitergehende Ausfuhrungsform sieht daher vor, die reinstanzierten SAs nur temporar solange einzusetzen, bis neu aufgestellte, auch bezuglich Replay-Attacken abgesicherte Sicherheitsvereinbarungen sowohl seitens der Anwendereinheit (UE) als auch seitens des Proxy-Servers (P-CSCF 2) vorliegen.
Eine Idee besteht darin, eine Anforderung (im folgenden auch Recovery Request oder abgekürzt „RR" genannt) zur Wiederherstellung der Verbindung vom Proxy-Server (P-CSCF 2) an die Anwendereinheit (UE) zu senden.
Die Anforderung (RR) wird mit Hilfe der Parameter gemäß der temporaren, auswärts gerichteten Sicherheitsvereinbarung (outbound SA) des Proxy-Servers (P-CSCF 2) geschützt. Gemäß dem ersten Aspekt der Erfindung geschieht die Übermittlung der Anforderung (RR) an die UE z.B. einschließlich der berechneten oder festgesetzten Sequenznummer.
Bevorzugt kann aber auch eine sog. „Network-Initiated Re- Registration" (übersetzt mit netzwerk-initiierter ReRegistrierung) ausgenutzt werden, die durch die Serving-CSCF (S-CSCF) angestoßen wird. Dazu wird, anstatt eine Anforderung (RR) an die Anwendereinheit (UE) abzusenden, eine entsprechende Anforderung oder Nachricht an die Serving-CSCF gesen- det mit dem Ziel, die Serving-CSCF (S-CSCF) anzutriggern, so dass diese die genannte Netzwerk-Re-Registrierung anstoßt. Die nachfolgenden Schritte können analog zur Registrierung wie bei Anstoßen der Re-registrierung über die Anwendereinheit (UE) verlaufen.
Einer ersten Ausgestaltung dieses Erfindungsgedankens zufolge wird der Aufbau neuer, abgesicherter SAs auf beiden Seiten (UE und P-CSCF 2) anhand eines speziellen Handshakes bewerk- stelligt. Ausgangspunkt ist bereits ein fest eingerichteter inbound SA sowie ein noch temporärer outbound SA beim Proxy- Server (P-CSCF 2) .
Auf die oben beschriebene Anforderung (RR) hin, mit welcher in diesem Fall zusätzlich auch SPI-indizes übermittelt werden, die auf die wiederhergestellten inbound SAs des Proxy- Servers (P-CSCF 2) zeigen, wird bei der Anwendereinheit (UE) deren alte, auswärts gerichtete Sicherheitsvereinbarung (out- bound SA) gelöscht. Des weiteren wird eine entsprechend neue inbound SA und eine neue outbound SA aufgestellt, die mit den wiederhergestellten SAs des zweiten Proxy-Servers (P-CSCF 2) kompatibel sind. Alte und neue inbound SA koexistieren zeitweilig auf Seite der Anwendereinheit (UE) . Sie können gemäß IPsec Spezifikation (RFC 2401) anhand ihrer unterschiedlichen SPI-Indizes auseinander gehalten werden. Die SPI-Indizes dienen der gegenseitigen Auswahl und Referenzierung von Sicherheitsvereinbarungen zwischen den Kommunikationspartnern.
Anschließend sendet die Anwendereinheit (UE) eine Antwort (Response to RR) an den Proxy-Server (P-CSCF 2) mit ihren entsprechenden SPI-Indizes. Anhand derer kann der Proxy- Server (P-CSCF 2) seine auswärtsgerichtete Sicherheitsvereinbarung (outbound SA) anpassen, d.h. erneuern. Mit anderen Worten, die alte outbound SA, anhand welcher der Recovery Re- quest (RR) geschützt wurde, wird nun gelöscht und ein neuer outbound SA seitens des Proxy-Servers (P-CSCF 2) wird aufgestellt, der mit den von der Anwendereinheit übermittelten SPI-Indizes kompatibel ist.
Der Proxy-Server (P-CSCF 2) bestätigt den Erhalt der Antwort gegenüber der Anwendereinheit (UE) , so dass letztere nun auch ihren alten inbound SA löschen kann.
Es ist anzumerken, dass je nach Verwendung von TCP oder UDP als Transportschicht-Protokoll entweder ein oder zwei reguläre SAs je Typ (outbound - inbound) und Partner (UE oder P- CSCF) vorliegen. Die Erfindung (alle Aspekte) schließt beide Fälle (UDP, TCP) ein, auch wenn in diesem Dokument jeweilige Sicherheitsvereinbarungen eines Typs und Partners häufig nur im Singular bezeichnet werden.
Eine zweite Ausgestaltung des Erfindungsgedankens bzgl. des Recovery Requests (RR) besteht darin, eine teils ungeschützte Re-Registrierung nach Absendung der Anforderung durchzuführen, die wie oben ausgeführt anhand der wiederhergestellten outbound SA durch den Proxy-Server (P-CSCF 2) geschützt wird. Die Anwendereinheit (UE) antwortet auf die Anforderung mit einer REGISTER-Anfrage gemäß SIP-Protokoll .
Eine Re-Registrierung dient allgemein dem Wechsel zu neuen Sicherheitsvereinbarungen während einer Session. Die Re- Registrierung unterscheidet sich von der anfänglichen Registrierung dadurch, dass sie authentifiziert durchgeführt wird. Insbesondere werden dabei normalerweise geschützte Ports verwendet, wobei die jeweils geschützten Server-Ports beim Wechsel von alten zu neuen Sicherheitsvereinbarungen sogar erhal- ten bleiben. Die konventionelle Registrierung ist im Standard 3GPP TS 33.203 in Kapitel 6.1.1, das Aufsetzen von SAs in Kapitel 7.2. und die Re-Registrierung in Kapitel 7.4. spezifiziert .
Vorliegend wird die an den Zielserver S-CSCF gerichtete REGISTER-Anfrage gemäß SIP-Protokoll über einen ungeschützten (unprotected) Client Port der Anwendereinheit (UE) zunächst an einen ungeschützten Server-Port des Proxy-Servers (P-CSCF 2) gesendet. Die Antwort vom Proxy-Server (P-CSCF 2) weist im Rahmen des IMS-AKA Protokolls für die Authentikation einen vom Server (S-CSCF) des Heimatnetzwerks erstellten Challenge- Wert auf (vgl. 3GPP TS 33.203, Kapitel 6.1.1). Der Unterschied zur geltenden Re-Registrierung besteht folglich in der Verwendung ungeschützter Ports sowie in einer Authentikation, die ähnlich wie bei der initialen Registrierung abläuft. Dabei markiert der Proxy-Server vor Weiterleitung der REGISTER- Anfrage and den Server (S-CSCF) diese als ungeschützt. Der Heimatnetzwerk-Server (S-CSCF) erkennt bzgl. der REGIS- TER-Anfrage, dass sie Teil einer Re-Registrierung in einer laufenden Verbindung ist. Er erkennt dies z.B. daran, dass einige der Registrierzustände unverändert bleiben, bzw. dass der Proxy-Server (P-CSCF) ihm die Authentikation der UE mitteilt. Der Zielserver S-CSCF führt eine Re-Registrierung immer dann durch, wenn der Proxy-Server diesem mitteilt, dass es sich um eine geschützte REGISTER-Nachricht handelt. Gleichwohl erkennt der Server (S-CSCF) , dass die Anfrage als ungeschützt markiert ist.
Entscheidend ist, dass die Serving-CSCF (S-CSCF) anhand einer Markierung der Nachricht durch den Proxy-Server (P-CSCF 2) ohne weiteres erkennen kann, welche Schritte nachfolgend durchzuführen sind.
Gemäß dieser Ausgestaltung behandelt der Server (S-CSCF) des Heimatnetzwerks die REGISTER-Anfrage als Teil einer Re- Registrierungsprozedur und nicht einer initialen Registrie- rung, denn diese würde den Abbruch der bisherigen SIP-Session bedeuten. Dennoch führt der Server (S-CSCF) eine erneute Pflichtauthentikation durch, die konventionell bei der ReRegistrierung nur optional durchgeführt wird.
Die Sicherheitsvereinbarungen (SA) zwischen Anwendereinheit (UE) und Proxy-Server (P-CSCF 2) werden bei der hier vorgeschlagenen Re-Registrierung neu ausgehandelt. Die neu ausgehandelten Sicherheitsvereinbarungen ersetzen demnach die alten SAs.
Ein zweiter Aspekt der Erfindung sieht vor, im Unterschied zum ersten Aspekt nicht die alten, regulären, wiederhergestellten Sicherheitsvereinbarungen (SA) zum Zweck der Verschlüsselung weiter zu verwenden, sondern vielmehr dedizierte Ausfall-Sicherheitsvereinbarungen (fail-over SAs) zu schaffen. Diese dienen ausschließlich der Wiederherstellung der laufenden Verbindung nach Ausfall des primären Proxy-Servers (P-CSCF 1) . Ein besonderer Vorteil, der sich durch solche von den regulären SAs separaten Ausfall-Sicherheitsvereinbarungen (fail- over SAs) bietet, ist der, dass mangels Verwendung dieser fail-over SAs vor einem Ausfall die Sequenznummer für abgesandte Nachrichten in vereinbarter Weise auf beiden Seiten (UE und P-CSCF 2) auf einem festen Wert, beispielsweise Null, steht. Dadurch besteht bei diesem Aspekt ein besonders hoher Grad an Sicherheit, insbesondere gegenüber Replay-Attacken nach Ausfall eines Proxy-Servers (P-CSCF 1) - ein Ereignis, das möglicherweise von Angreifern abgepasst werden könnte.
Die zum ersten Aspekt beschriebenen Ausgestaltungen, welche zum einen die Aufstellung neuer regulärer SAs im Rahmen eines (two-way) Handshakes beschreiben, zum anderen die Aufstellung neuer regulärer SAs im Rahmen einer angepassten, aber grundsätzlich dem standardisierten Fall ähnlichen Re-Registrierung beschrieben, gelten auch für den Aspekt der fail-over SAs, nur dass eben letztere als zusätzliche SAs aufgebaut bzw. gehalten werden müssen.
Wie beschrieben dienen die fail-over SAs der Verschlüsselung und Sicherung des Recovery Requests (RR) . Es liegt in beiden (zum ersten Aspekt analogen) Ausgestaltungen seitens des Pro- xy-Servers (P-CSCF 2) eine outbound fail-over SA vor, seitens der Anwendereinheit eine inbound fail-over SA. Beide fail- over SAs bilden ein zusammengehöriges Paar.
Auf Seite der Anwendereinheit (UE) wird die fail-over SA dau- erhaft gehalten, bis der Ausfall des Kommunikationspartners eintritt. Die fail-over SA wird dabei eingesetzt und verbraucht. D.h., sie wird nach Einsatz gelöscht und durch eine neue fail-over SA ersetzt, die mit dem Proxy-Server (P-CSCF 2) ausgehandelt wird.
Auf Seite der Proxy-Server (P-CSCF 1 und 2) wird die Information lediglich in der Anwendungsschicht im ersten Proxy- Server (P-CSCF 1) gehalten, d.h., es findet kein dauerhafter Aufbau einer fail-over SA statt. Sie kann und soll nämlich während einer noch nicht ausgefallenen Verbindung nicht eingesetzt werden. Erst nach dem Ausfall und dem Replizieren der Sicherheitsinformationen auf dem zweiten und bisherigen Standby-Proxy-Server (P-CSCF 2) wird aus diesen Informationen der Anwendungsschicht heraus eine dedizierte fail-over SA aufgestellt. Der Unterschied zwischen einem alleinigen Halten der fail-over SA-Information in der Anwendnungsschicht und einer expliziten Aufstellung der fail-over SA nach dem Aus- fall besteht in der Abspeicherung in einer gesonderten Sicherheitsdatenbank, in der SAs von außen durch Referenzieren anhand von SPI-Zeigern angesprochen werden können.
Ein dritter Aspekt der Erfindung betrifft das Anstoßen (Trig- gern) einer angepassten Re-Registrierung, so wie eingangs beim ersten Aspekt beschrieben, jedoch ohne dass hierbei eine Verschlüsselung der Anforderung bzw. des Recovery Requests (RR) über Sicherheitsvereinbarungen - weder über reguläre noch über fail-over SAs - erfolgt.
Eine Ausgestaltung des dritten Aspekts sieht vor, ein separates, vorab abgestimmtes Geheimnis, das auf shared-key- Material basiert, einzurichten, mit dem die Verschlüsselung der Triggernachricht (Anforderung RR) erfolgt.
Eine weitere Ausgestaltung des dritten Aspekts sieht vor, keine weitere Zustandsänderung der Registrierung nach Wiederherstellung mehr zuzulassen, d.h. ein Verbot weiterer ReRegistrierungen der laufenden Session. Dies kann beispiels- weise durch Setzen eines Flags auf Seite des Proxy-Servers (P-CSCF 2) geschehen, der die laufende Session kennzeichnet und nach Beendigung der Verbindung wieder gelöscht wird.
Ein weitere Ausgestaltung des dritten Aspekts sieht vor, die Anzahl der zulässigen Anforderungen auf Wiederherstellung einer Session bzw. Verbindung innerhalb eines festgelegten Zeitraums nach dem Ausfall zu begrenzen. Die Erfindung soll nun anhand eines Ausführungsbeispiels mit Hilfe von Zeichnungen näher erläutert werden. Darin zeigen:
Figur 1: den grundsätzlichen Aufbau eines IMS-Systems gemäß 3GPP;
Figuren 2 - 4: Flussdiagramme mit aufeinanderfolgenden Schritten eines two-way-Handshakes für die Wiederherstellung von SAs einer laufenden Verbindung zwischen Anwendereinheit (UE) und Proxy-Server (P-CSCF 2) unter Verwendung vorab vereinbarter fail-over SAs.
Figur 1 zeigt den grundsätzlichen Aufbau eines IMS-Systems gemäß 3GPP, so wie er in diesem Dokument eingangs beschrieben ist. Die Massnahmen gemäß dem nun zu beschreibenden Ausführungsbeispiel beziehen sich auf einen Handshake, d.h. einem Informationsaustausch, zwischen der Anwendereinheit (UE) , genauer gesagt: dessen User Agent (UA), und dem zweiten Proxy- Server (P-CSCF 2), der nach einem Ausfall eines ersten Proxy- Servers (P-CSCF 1) dessen Funktion der Vermittlung von Nachrichten vom und zum Server (S-CSCF) übernimmt. Die im folgenden beschriebenen SAs beziehen sich also auf den die Verbindung UA - P-CSCF darstellenden Pfeil in Fig. 1.
Figur 2 zeigt einen ersten Teil eines Flussdiagramms, mit welchem dieser Handshake erläutert werden soll. Der Handshake wird außerhalb einer Registrierung oder Re-Registrierung durchgeführt und läuft daher außerhalb derzeit festgelegter Standards ab.
Vor dem Ausfall des ersten Proxy-Servers (P-CSCF 1) liegen auf beiden Seiten (UE und P-CSCF 1) jeweils Paare von regulären inbound und outbound SAs vor. Darüber hinaus wurde eine fail-over SA vereinbart, die auch als solche bei der Anwen- dereinheit (UE) hinterlegt ist. Die in der fail-over SA vorhandenen serverseitigen Informationen (Sicherheitsparameter) sind auch in der Anwendungsschicht beim Proxy-Server (P-CSCF 1) vorhanden, ohne dass daraus aber eine eigene fail- over SA im Proxy-Server (P-CSCF 1) erstellt wird.
Die Art und Weise, wie der fail-over SA erstellt wird, geht aus dem weiteren Ablauf gemäß Fig. 2 - 4 hervor. Die alten, regulären SAs vor dem Ausfall werden gemäß dem Stand der Technik im Rahmen einer Erstregistrierung im Security-Mode erstellt (vgl. 3GPP TS 33.203 (Kapitel 7.2) und RFC 3329).
Die Sicherheitsparameter der regulären SAs umfassen: sog. Se- lectors, z.B. IP-Adressen (Source und Destination, gebunden an SIP-Fluss), Transportprotokolle (TCP oder UDP, wird ausgehandelt) , geschützte Portadressen (Source und Destination, gebunden an SIP-Fluss), weiter Algorithmen (encryption und integrity) , zugeordnete SPI-Zeiger für inbound SAs, Lebensdauer (in Sekunden, wird ausgehandelt), aktuelle und maximale Sequenznummer (letzteres wird ausgehandelt, z.B. 2^1 - 1), Länge des Schlüssels für Integritätsalgorithmus (wird ausgehandelt, z.B. 128 bit für HMAC-MD5-96 oder 160 bit für HMAC- SHA-1-96), Länge des Schlüssels für Encyption (wird ausgehandelt, z.B. für DES-EDE3-CBC (RFC 2451) oder AES-CBC (RFC 3602) mit mindestens 128 bit) .
Der Ausfall des ersten Proxy-Servers (P-CSCF 1) wird dem zweiten Standby-Proxy-Server (P-CSCF 2) signalisiert. Dieser übernimmt sofort die IP-Adresse des ersten Proxy-Servers (P-CSCF 1) .
Des weiteren repliziert er die Daten der Anwendungsschicht des ersten Proxy-Servers (P-CSCF 1), insbesondere der sicherheitsrelevanten Informationen der regulären SAs, wie sie vor dem Ausfall bestand hatten.
Basierend auf diesen Informationen werden vom zweiten Proxy- Server (P-CSCF 2) neue reguläre inbound SAs erstellt.
Auch eine fail-over SA wird erstellt. Für die outbound fail- over SA des Proxy-Servers (P-CSCF 2) sind z.B. folgende Si- cherheitsparameter erforderlich: eigene Source- und fremde Destination-Port-Nummer der Anwendereinheit (UE) , der durch die Anwendereinheit (UE) dieser fail-over SA zugeordnete SPI- Wert. Die IP-Adressen sind die gleichen wie für die regulären SAs. Der geschützte (protected) Server-Port der UE ist durch die Replikation der Anwendungsschicht bekannt und wird für die fail-over SA vorzugsweise als Destination-Port gewählt. Der geschützte Client-Port des Proxy-Servers (P-CSCF 2) dieser fail-over SA muss dann aus Gründen der Eindeutigkeit an- ders als derjenige für die regulären SAs gewählt werden. Als Sequenznummer gilt der Wert Null.
Der Proxy-Server (P-CSCF 2) alloziiert neue SPI-indizes (spi- pc und spi-ps) für die regulären inbound SAs (wg. ausgewähl- tem UDP-Protokoll sind dies hier zwei anstatt nur eines SAs (TCP) an der Zahl) .
Anhand des mittels der Replikation ebenfalls bekannten Schlüssels und des zugehörigen Algorithmus der fail-over SA wird eine Anforderung (RR) erzeugt und an die Anwendereinheit (UE) gesandt. Mit der Nachricht werden auch die SPI-Indizes (spi-pc und spi-ps) übermittelt. Die Sequenznummer zählt durch diese Verwendung um den Zähler „1" hoch.
Fig. 3 zeigt die Fortsetzung des Flussdiagrams aus Figur 2. Der Recovers-Request (RR) wird empfangen und aufgrund der noch bestehenden alten fail-over SA zugelassen (entschlüsselt, verifiziert, authentifiziert etc.) . Insbesondere ist die empfangene Sequenznummern größer als die bei der UE vor- handene, denn die inbound failover SA der UE ist bisher noch nicht eingesetzt worden. In der Anwendereinheit (UE) werden daraufhin die alten regulären SAs entfernt, da sie nicht mehr benötigt werden. Neue inbound und outbound SAs werden aufgestellt. Erstere werden eigens zu diesem Zweck alloziierten SPI-Indizes (spi-uc und spi-us) zugeordnet.
Es wird ferner eine neue inbound fail-over SA aufgestellt und ebenfalls einem alloziierten SPI-Index (spi-f) zugeordnet. Die SPI-Indizes (spi-uc, spi-us und spi-f) werden nun in eine Antwort (response) auf die Anforderung (recovery request) ge- fasst und geschützt (Integrity und Encryption) gemäß den Ver- einbarungen, auf die der Index spi-ps zeigt. Die Antwort wird an den Proxy-Server (P-CSCF 2) übermittelt. Dabei wird die Nachricht vom Port port_uc der Anwendereinheit UE via UDP an den port_ps des Proxy-Servers (P-CSCF 2) gesendet (zu den Portbezeichnungen siehe 3GPP TS 33.203 Version 7.0.0 Release 7, Seite 21-23) .
Der Proxy-Server (P-CSCF 2) erstellt seinerseits neue reguläre outbound SAs anhand der erhaltenen Informationen (SPI- Zeiger) . Außerdem wird der eingangs erstellte, aber nunmehr veraltete outbound failover SA des Proxy-Servers (P-CSCF 2) gelöscht. Nunmehr liegen auf Seite der Anwendereinheit zwei parallel existierende fail-over SAs vor (alt und neu) , und auf Seite des Proxy-Servers (P-CSCF 2) liegt keine fail-over SA mehr vor. Dagegen besitzt der Proxy-Server (P-CSCF 2) auf- grund der durch spi-f aufgezeigten Informationen Zugang zu den Sicherheitsparametern der neuen fail-over SA der UE, wobei er diese Parameter lediglich in der Anwendungsschicht hält.
Die Situation ist in Fig. 4 dargestellt, deren gezeigtes
Flussdiagramm sich an dasjenige aus Fig. 3 anschließt. Gemäß SIP-Nachricht wird vom Proxy-Server (P-CSCF 2) der Empfang von spi-f an die Anwendereinheit (UE) bestätigt. Dazu wird anhand der neuen outbound SA und nicht mehr der alten fail- over SA vorgegangen, was die Verschlüsselung betrifft. Die Anwendereinheit (UE) entfernt infolgedessen die alte fail- over SA, so dass nur noch die neue inbound fail-over SA verbleibt.
Somit ist wieder die Situation hergestellt, die zu Anfang des Flussdiagramms in Fig. 2 bestand. Das System würde also auch auf einen zweiten Ausfall reagieren können. Es ist anzumerken, dass die vorgenannten Ausgestaltungen und Beispiele in diesem Dokument auch für bidirektionale Sicherheitsvereinbarungen (reguläre und fail-over SAs) anwendbar sind und dass die entsprechend möglichen Ausführungsformen von der Erfindung mit umfasst sein sollen.

Claims

Patentansprüche
1. Verfahren zum Wiederherstellen einer mit IPsec kryp- tographisch gesicherten Verbindung zwischen einem zweiten Proxy-Server (P-CSCF 2) und einer gegenüber einem Server
(S-CSCF) registrierten Anwendereinheit (UE), nachdem ein erster Proxy-Server (P-CSCF 1) in einem von der Anwendereinheit (UE) besuchten Netzwerk (VN) ausgefallen ist, welcher vor dem Ausfall zur Vermittlung von zwischen dem Server (S-CSCF) und der Anwendereinheit (UE) versandten Nachrichten eingerichtet war, umfassend:
Bereitstellen eines zweiten Proxy-Servers (P-CSCF 2) in dem besuchten Netzwerk (VN) ;
Übernehmen einer IP-Adresse des ersten Proxy-Servers (P-CSCF 1) durch den zweiten Proxy-Server (P-CSCF 2), so dass dieser an die Stelle des ersten Proxy-Servers (P-CSCF 1) bezuglich der Vermittlung von Nachrichten tritt;
Replizieren von Informationen betreffend die kryp- tographische Sicherheit der Verbindung in dem zweiten Proxy- Server (P-CSCF 2), welche zuletzt vor dem Ausfall in der Anwendungsschicht im ersten Proxy-Server (P-CSCF 1) gespeichert waren;
Verwenden der replizierten Informationen zur Erstellung wenigstens einer Sicherheitsvereinbarung (SA) zwischen dem zweiten Proxy-Server (P-CSCF 2) und der Anwendereinheit (UE) in dem Proxy-Server (P-CSCF 2), anhand welcher nachfolgend eine Verschlüsselung der vermittelten Nachrichten durchgeführt wird.
2. Verfahren nach Anspruch 1, bei dem vom zweiten Proxy- Server (P-CSCF 2) wenigstens zwei reguläre Sicherheitsvereinbarungen (inbound SA, outbound SA) erstellt werden, indem Sicherheitsparameter mit Ausnahme jeweils des Sicherheitsparameters Sequenznummer aus denjenigen regulären Sicherheitsver- einbarungen aus den replizierten Informationen übernommen werden, die vor dem Ausfall im ersten Proxy-Server (P-CSCF 1) bestand hatten.
3. Verfahren nach Anspruch 2, bei dem bei der Wiederherstellung einer auswärts gerichteten regulären Sicherheitsvereinbarung (outbound SA) der Sicherheitsparameter Sequenznummer vom Proxy-Server (P-CSCF 2) mit einer Zahl besetzt wird, die größer als der Wert Null ist, so dass eine mit der Sequenznummer versehene Nachricht nicht aufgrund eines Zahlenvergleichs mit einer dem zweiten Proxy-Server (P-CSCF 2) unbekannten, aber der Anwendereinheit (UE) bekannten Sequenznummer, die Gegenstand einer regulären Sicherheitsvereinbarung war, die vor dem Ausfall im ersten Proxy-Server (P-CSCF 1) bestand hatte, von der Anwendereinheit (UE) zurückgewiesen wird.
4. Verfahren nach Anspruch 3, bei dem die zu setzende Zahl für die Sequenznummer ausgehender Nachrichten in einem API- Interface zwischen Anwendung und Betriebssystem auf dem Proxy-Server (P-CSCF 2) fest hinterlegt wird.
5. Verfahren nach Anspruch 3, bei dem die zu setzende Zahl für die Sequenznummer ausgehender Nachrichten vom Proxy- Server (P-CSCF 2) als lokal größter darstellbarer Wert ausgewählt wird.
6. Verfahren nach Anspruch 3, bei dem die zu setzende Zahl für die Sequenznummer ausgehender Nachrichten vom Proxy- Server (P-CSCF 2) aus Angaben über die Zahl innerhalb der laufenden Verbindung versendeter Nachrichten oder Bytes, die er aus den replizierten Informationen ausliest, berechnet wird.
7. Verfahren nach Anspruch 3, bei dem eine frühere Sequenznummer ausgehender Nachrichten, die Gegenstand einer regulären Sicherheitsvereinbarung war, die vor dem Ausfall im ersten Proxy-Server (P-CSCF 1) bestand hatte, vom Proxy-Server (P-CSCF 2) vor dem Ausfall in regelmäßigen Abständen von dem noch nicht ausgefallenen Proxy-Server (P-CSCF 1) abgefragt und gespeichert wird, und bei dem der Schritt der Wiederherstellung der auswärtsgerichteten Sicherheitsvereinbarung (outbound SA) die Berechnung der zu setzenden Zahl anhand der ausgelesenen und gespeicherten, früheren Sequenznummer durch den zweiten Proxy-Server (P-CSCF 2) umfasst.
8. Verfahren nach Anspruch 2, bei dem bei der Wiederherstellung einer einwärts gerichteten regulären Sicherheitsvereinbarung (inbound SA) ein Anfangswert für die Sequenznummer eingehender Nachrichten auf Null gesetzt wird.
9. Verfahren nach Anspruch 8, bei dem der zweite Proxy-Server (P-CSCF 2) nach der Wiederherstellung lediglich noch solche die Registrierung der Anwendereinheit (UE) gegenüber dem Server (S-CSCF) betreffenden Nachrichten zulasst und weitervermittelt und die übrigen Nachrichten zurückweist.
10. Verfahren nach einem der Ansprüche 2 bis 9, bei dem der zweite Proxy-Server (P-CSCF 2) nach Wiederherstellung der regulären Sicherheitsvereinbarungen (inbound SA, outbound SA) eine Anforderung (RR) zur Wiederherstellung der Verbindung an die Anwendereinheit sendet.
11. Verfahren nach einem der Ansprüche 2 bis 9, bei dem der zweite Proxy-Server (P-CSCF 2) nach Wiederherstellung der regulären Sicherheitsvereinbarungen (inbound SA, outbound SA) durch Übermittlung einer Nachricht an den Serving CSCF (S- CSCF) eine netzwerk-initiierte Re-Registration anstoßt, die vom Serving CSCF (S-CSCF) gestartet wird.
12. Verfahren nach Anspruch 10, bei dem die Anforderung (RR) mit einem Schlüssel und einem Algorithmus geschützt wird, welche Sicherheitsparameter einer der wiederhergestellten Sicherheitsvereinbarungen (outbound SA) sind.
13. Verfahren nach Anspruch 12, bei dem nach Empfang der An- forderung (RR) durch die Anwendereinheit (UE) eine ReRegistrierung gegenüber dem Serving-CSCF (S-CSCF) angestoßen wird, so dass in dessen Verlauf die wiederhergestellten Sicherheitsvereinbarungen (inbound SA, outbound SA) in dem zweiten Proxy-Server (P-CSCF 2) durch neu vereinbarte Sicherheitsvereinbarungen ersetzt, und auch in der Anwendereinheit (UE) vorhandene alte Sicherheitsvereinbarungen durch neue Sicherheitsvereinbarungen werden.
14. Verfahren nach Anspruch 13, bei dem die Re-Registrierung über ungeschützte Ports der Anwendereinheit (UE) und des Proxy-Servers (P-CSCF 2) über eine REGISTER-Anfrage gemäß SIP- Protokoll initialisiert wird, und bei dem der zweite Proxy- Server (P-CSCF 2) die REGISTER-Anfrage als ungeschützt markiert und an den Serving-CSCF (S-CSCF) weiterleitet.
15. Verfahren nach Anspruch 14, bei dem der Serving-CSCF (S-CSCF) aus der REGISTER-Anfrage erkennt, dass eine als un- geschützt markierte Re-Registrierung erfolgen soll und in
Antwort darauf eine Pflichtauthentikation mit einem erneuten Aushandeln von Sicherheitsvereinbarungen durchführt.
16. Verfahren nach Anspruch 12, bei dem lediglich auswärtsge- richtete, reguläre Sicherheitsvereinbarungen (outbound SA) beim Proxy-Server (P-CSCF 2) wiederhergestellt werden.
17. Verfahren nach Anspruch 16, bei dem mit der Anforderung (RR) SPI-Indizes (spi-pc, spi-ps) wenigstens einer zusätzli- chen, neu aufgestellten, einwärts gerichteten Sicherheitsvereinbarung (inbound SA) vom Proxy-Server (P-CSCF 2) an die Anwendereinheit (UE) versendet werden.
18. Verfahren nach Anspruch 17, bei dem die Anwendereinheit (UE) unter Verwendung wenigstens einer alten, von ihr vor dem
Ausfall aufgestellten, einwärts gerichteten, regulären Sicherheitsvereinbarung (inbound SA) die Anfrage empfängt.
19. Verfahren nach Anspruch 18, bei dem die Anwendereinheit (UE) wenigstens eine neue, einwärts gerichtete Sicherheitsvereinbarung (inbound SA) sowie wenigstens eine neue auswärts gerichtete Sicherheitsvereinbarung (outbound SA) aufstellt, und der wenigstens einen einwärts gerichteten Sicherheitsver- einbarung (inbound SA) jeweils einen SPI-Index (spi-uc, spi- us) zuordnet.
20. Verfahren nach Anspruch 19, bei dem die Anwendereinheit (UE) eine Antwort (response) an den Proxy-Server (P-CSCF 2) sendet, welche anhand einer der vom zweiten Proxy-Server (P- CSCF 2) empfangenen SPI-Indizes (spi-ps) geschützt wird und welche die den einwärts gerichteten Sicherheitsvereinbarungen (inbound SA) der Anwendereinheit (UE) zugeordneten SPI- Indizes (spi-uc, spi-us) enthält.
21. Verfahren nach Anspruch 20, bei dem der Proxy-Server (P-CSCF 2) die Antwort (response) unter Verwendung der wenigstens einen einwärts gerichteten regulären Sicherheitsver- einbarung (inbound SA) empfängt und den gesicherten Inhalt entnimmt .
22. Verfahren nach Anspruch 21, bei dem der Proxy-Server (P-CSCF 2) auf den Empfang der Antwort (response) hin eine Bestätigung an die Anwendereinheit (UE) sendet.
23. Verfahren nach Anspruch 22, bei dem die Anwendereinheit (UE) auf den Empfang der Bestätigung von dem zweiten Proxy- Server (P-CSCF 2) hin die alte, von ihr vor dem Ausfall auf- gestellte, einwärts gerichtete, regulären Sicherheitsvereinbarung (inbound SA) löscht.
24. Verfahren nach Anspruch 1, bei dem vom zweiten Proxy- Server (P-CSCF 2) wenigstens eine auswärtsgerichtete Ausfall- Sicherheitsvereinbarung (outbound fail-over SA) erstellt wird, indem Sicherheitsparameter aus denjenigen regulären Sicherheitsvereinbarungen aus den replizierten Informationen übernommen werden, die vor dem Ausfall im ersten Proxy-Server (P-CSCF 1) bestand hatten, wobei der Ausfall-Sicher- heitsvereinbarung (fail-over SA) zusätzlich eine Sequenznummer mit festem Wert zugeordnet ist.
25. Verfahren nach Anspruch 24, bei dem die erstellte, auswärtsgerichtete Ausfall-Sicherheitsvereinbarung (outbound fail-over SA) des Proxy-Servers (P-CSCF 2) einer bereits vor dem Ausfall vorhandenen einwärts gerichteten Sicherheitsver- einbarung (inbound fail-over SA) der Anwendereinheit (UE) zugeordnet ist.
26. Verfahren nach Anspruch 25, bei dem eine Anforderung (RR) zur Wiederherstellung der Verbindung vom Proxy-Server (P-CSCF 2) an die Anwendereinheit (UE) gesendet wird.
27. Verfahren nach Anspruch 26, bei dem die Anforderung (RR) mit einem Schlüssel und einem Algorithmus geschützt wird, welche Sicherheitsparameter der auswärts gerichteten Ausfall- Sicherheitsvereinbarung (outbound fail-over SA) des Proxy- Servers (P-CSCF 2) sind.
28. Verfahren nach Anspruch 27, bei dem nach Empfang der Anforderung (RR) durch die Anwendereinheit (UE) eine Re- Registrierung gegenüber dem Server (S-CSCF) angestoßen wird, so dass in dessen Verlauf in dem zweiten Proxy-Server (P-CSCF 2) neue reguläre Sicherheitsvereinbarungen (inbound SA, outbound SA) erstellt, und auch in der Anwendereinheit (UE) neue reguläre Sicherheitsvereinbarungen (inbound SA, outbound SA) erstellt werden.
29. Verfahren nach Anspruch 28, bei dem die Re-Registrierung über ungeschützte Ports der Anwendereinheit (UE) und des Proxy-Servers (P-CSCF 2) über eine REGISTER-Anfrage gemäß SIP- Protokoll initialisiert wird, und bei dem der zweite Proxy- Server (P-CSCF 2) die REGISTER-Anfrage als ungeschützt markiert und an den Server (S-CSCF) weiterleitet.
30. Verfahren nach Anspruch 29, bei dem der Server (S-CSCF) aus der REGISTER-Anfrage erkennt, dass eine als ungeschützt markierte Re-Registrierung erfolgen soll und in Antwort darauf eine Pflichtauthentikation mit einem erneuten Aushandeln zum Aufstellen der neuen Sicherheitsvereinbarungen in der An- wendereinheit (UE) und dem zweiten Proxy-Server (P-CSCF 2) durchführt .
31. Verfahren nach Anspruch 27, bei dem mit der Anforderung (RR) SPI-Indizes (spi-pc, spi-ps) wenigstens einer zusätzlichen, neu aufgestellten, einwärts gerichteten Sicherheitsvereinbarung (inbound SA) vom Proxy-Server (P-CSCF 2) an die Anwendereinheit (UE) versendet werden.
32. Verfahren nach Anspruch 31, bei dem die Anwendereinheit
(UE) unter Verwendung der einwärts gerichteten, regulären Sicherheitsvereinbarung (inbound SA) die Anfrage empfängt.
33. Verfahren nach Anspruch 32, bei dem die Anwendereinheit (UE) wenigstens eine neue, einwärts gerichtete Sicherheitsvereinbarung (inbound SA), wenigstens eine neue auswärts gerichtete Sicherheitsvereinbarung (outbound SA) und eine neue einwärts gerichtete Ausfall-Sicherheitsvereinbarung (inbound fail-over SA) aufstellt, wobei sie der wenigstens einen ein- wärts gerichteten Sicherheitsvereinbarung (inbound SA) jeweils einen SPI-Index (spi-uc, spi-us) und der einwärts gerichteten Ausfall-Sicherheitsvereinbarung einen SPI-Index (spi-f) zuordnet.
34. Verfahren nach Anspruch 33, bei dem die Anwendereinheit (UE) eine Antwort (response) an den Proxy-Server (P-CSCF 2) sendet, welche anhand einer der vom zweiten Proxy-Server (P-CSCF 2) empfangenen SPI-Indizes (spi-ps) geschützt wird und welche die den einwärts gerichteten Sicherheitsvereinba- rungen (inbound SA) der Anwendereinheit (UE) zugeordneten SPI-Indizes (spi-uc, spi-us) sowie den der Ausfall-Sicherheitsvereinbarung (inbound fail-over SA) zugeordneten SPI- Index (spi-f) enthält.
35. Verfahren nach Anspruch 34, bei dem der Proxy-Server
(P-CSCF 2) die Antwort (response) unter Verwendung der wenigstens einen einwärts gerichteten regulären Sicherheitsver- einbarung (inbound SA) empfängt und den gesicherten Inhalt entnimmt .
36. Verfahren nach Anspruch 35, bei dem der Proxy-Server (P-CSCF 2) auf den Empfang der Antwort (response) hin eine Bestätigung implizit im Rahmen einer nachfolgenden Nachricht an die Anwendereinheit (UE) sendet.
37. Verfahren nach Anspruch 36, bei dem der Proxy-Server (P-CSCF 2) die durch den der Ausfall-Sicherheitsvereinbarung (inbound fail-over SA) zugeordneten SPI-Index (spi-f) enthaltenen Sicherheitsinformationen in der Anwendungsschicht gespeichert hält, so dass sie bei einem erneuten Ausfall repliziert werden können.
38. Verfahren nach Anspruch 37, bei dem die Anwendereinheit (UE) auf den Empfang der Bestätigung von dem zweiten Proxy- Server (P-CSCF 2) hin die alte, einwärts gerichtete Ausfall- Sicherheitsvereinbarung (inbound fail-over SA) löscht.
39. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der erste und der zweite Proxy-Server (P-CSCF 1, P-CSCF 2) Cluster Nodes desselben physikalischen Servers in Cluster-Konfiguration repräsentieren .
PCT/EP2007/052164 2006-03-29 2007-03-08 Verfahren zum wiederherstellen einer mit ipsec kryptographisch gesicherten verbindung zwischen p-cscf und anwendereinheit WO2007113073A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102006014594A DE102006014594A1 (de) 2006-03-29 2006-03-29 Verfahren zum Wiederherstellen einer mit IPsec kryptographisch gesicherten Verbindung
DE102006014594.1 2006-03-29

Publications (1)

Publication Number Publication Date
WO2007113073A1 true WO2007113073A1 (de) 2007-10-11

Family

ID=38268982

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2007/052164 WO2007113073A1 (de) 2006-03-29 2007-03-08 Verfahren zum wiederherstellen einer mit ipsec kryptographisch gesicherten verbindung zwischen p-cscf und anwendereinheit

Country Status (2)

Country Link
DE (1) DE102006014594A1 (de)
WO (1) WO2007113073A1 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2453752A (en) * 2007-10-17 2009-04-22 Ericsson Telefon Ab L M Proxy mobile IP communications network
WO2013159804A1 (en) * 2012-04-23 2013-10-31 Nokia Siemens Networks Oy Failover functionality for client-related security association
EP3100434A4 (de) * 2014-01-29 2017-08-30 Honeywell International Inc. Vorrichtung und verfahren zum aufbau einer sicheren kommunikation mit redundanter vorrichtung nach umschaltung

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3799379B1 (de) * 2019-09-27 2023-03-01 Deutsche Telekom AG Verfahren und ip-basiertes kommunikationssystem zum wechseln von verbindungs-steuerungsinstanzen ohne neuregistrierung von endteilnehmern

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030018813A1 (en) * 2001-01-17 2003-01-23 Antes Mark L. Methods, systems and computer program products for providing failure recovery of network secure communications in a cluster computing environment
US20050071455A1 (en) * 2001-12-31 2005-03-31 Samsung Electronics Co., Ltd. System and method for scalable and redundant COPS message routing in an IP multimedia subsystem

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7082130B2 (en) * 2002-06-13 2006-07-25 Utstarcom, Inc. System and method for point-to-point protocol device redundancey

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030018813A1 (en) * 2001-01-17 2003-01-23 Antes Mark L. Methods, systems and computer program products for providing failure recovery of network secure communications in a cluster computing environment
US20050071455A1 (en) * 2001-12-31 2005-03-31 Samsung Electronics Co., Ltd. System and method for scalable and redundant COPS message routing in an IP multimedia subsystem

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); 3G security; Access security for IP-based services (3GPP TS 33.203 version 7.0.0 Release 7); ETSI TS 133 203", ETSI STANDARDS, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE, SOPHIA-ANTIPO, FR, vol. 3-SA3, no. V700, December 2005 (2005-12-01), pages 1 - 48, XP014032871, ISSN: 0000-0001 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2453752A (en) * 2007-10-17 2009-04-22 Ericsson Telefon Ab L M Proxy mobile IP communications network
WO2013159804A1 (en) * 2012-04-23 2013-10-31 Nokia Siemens Networks Oy Failover functionality for client-related security association
CN104247374A (zh) * 2012-04-23 2014-12-24 诺基亚通信公司 用于客户端相关的安全关联的故障转移功能
US9417975B2 (en) 2012-04-23 2016-08-16 Nokia Solutions And Networks Oy Failover functionality for client-related security association
KR101777187B1 (ko) 2012-04-23 2017-09-11 노키아 솔루션스 앤드 네트웍스 오와이 클라이언트­관련 보안 연관에 대한 페일오버 기능성
EP3100434A4 (de) * 2014-01-29 2017-08-30 Honeywell International Inc. Vorrichtung und verfahren zum aufbau einer sicheren kommunikation mit redundanter vorrichtung nach umschaltung

Also Published As

Publication number Publication date
DE102006014594A1 (de) 2007-10-04

Similar Documents

Publication Publication Date Title
DE602004007301T2 (de) Adressierungs-verfahren und -vorrichtung zum aufbau von hip-verbindungen zwischen gewöhnlichen und hip-fähigen netzknoten
DE602004007303T2 (de) Identifizierungs-verfahren und -vorrichtung zum aufbau von hip-verbindungen zwischen gewöhnlichen und hip-fähigen netzknoten
DE60122782T2 (de) Adressierungsverfahren und system zur verwendung einer anycast-adresse
DE60017292T2 (de) Authentifizierungsverfahren zwischen einem Teilnehmer und einem Dienstleister, der durch einen Netzbetreiber erreichbar ist, mittels Bereitstellung eines gesicherten Kanals
EP1982494B1 (de) Verfahren, vorrichtung und computerprogrammprodukt zum verschlüsselten übertragen von mediendaten zwischen dem medienserver und dem teilnehmergerät
DE60109993T2 (de) Verfahren zur überprüfung der menge übermittelter daten
EP1726178B1 (de) Verfahren zur Steuerung und Auswertung eines Nachrichtenverkehrs einer Kommunikationseinheit durch eine erste Netzwerkeinheit innerhalb eines Mobilfunksystems, sowie dazugehörige Kommunikationseinheit und erste Netzwerkeinheit
WO2004075584A1 (de) Verfahren zum bilden und verteilen kryptographischer schlüssel in einem mobilfunksystem und mobilfunksystem
EP1826956A1 (de) Anpassung von virtuellen und physikalischen Netzwerkschnittstellen
DE10142959A1 (de) Verfahren, System und Rechner zum Aushandeln einer Sicherheitsbeziehung auf der Anwendungsschicht
EP2014010B1 (de) Verfahren, vorrichtungen und computerprogrammprodukt zum ver- und entschlüsseln von mediendaten
DE10138718A1 (de) Verfahren zur Übermittlung von Chiffrierungsinformationen an Teilnehmer einer Multicast-Gruppe
DE60304100T2 (de) Erzwingung eines Zeitpunktes zur Trennung einer Kommmunikationsverbindung mit schnurlosen Endgeräten mit transienten Netzwerkadressen
EP3799379B1 (de) Verfahren und ip-basiertes kommunikationssystem zum wechseln von verbindungs-steuerungsinstanzen ohne neuregistrierung von endteilnehmern
DE102016115193A1 (de) Verfahren zur sicheren Datenhaltung in einem Computernetzwerk
EP1673921B1 (de) Verfahren zur sicherung des datenverkehrs zwischen einem mobilfunknetz und einem ims-netz
EP1721235B1 (de) Kommunikationssystem und verfahren zur bereitstellung eines mobilen kommunikationsdienstes
WO2007113073A1 (de) Verfahren zum wiederherstellen einer mit ipsec kryptographisch gesicherten verbindung zwischen p-cscf und anwendereinheit
EP1597861B1 (de) Verfahren zur übertragung von daten in einem wlan-netz
WO2008031515A1 (de) Verfahren und system zur adressierung und zum routing bei verschlüsselten kommunikationsbeziehungen
DE112013001411B4 (de) Optimieren mobiler Datenübertragung unter Verwendung von Byte-Caching
EP3149913B1 (de) System und verfahren für eine sichere und anonyme kommunikation in einem netzwerk
EP1709764A1 (de) Schaltungsanordnung und verfahren zur kommunikationssicherheit innerhalb von kommunikationsnetzen
DE102006038599B3 (de) Verfahren zur Wiederaktivierung einer sicheren Kommunikationsverbindung
EP1844603A1 (de) Verfahren zur sicherung der kommunikationsverbindungen und der zugeh\rigen vergeb]hrungen in einem redundanten kommunikationsnetzwerk

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: 07712478

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07712478

Country of ref document: EP

Kind code of ref document: A1