-
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 Übertragungssysteme
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 Berücksichtigung
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 Übertragung
im leicht zugänglichen
Radiofrequenzbereich zwischen Anwendereinheit (UE, user equipment)
und dem Zugangspunkt (AN, access network), als auch die Infrastruktur
für die
Signalübertragung
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-Konnektivität angeboten
(IP: internet protocol). Es werden somit für die mobile Kommunikation
bereits aus rechnerbasierten Netzwerkarchitekturen bekannte Lösungen ü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 1 gezeigt.
Eine Anwendereinheit (UE) umfasst ein IP-Services Indentitätsmodul (ISIM),
das eine Zusammenstellung von Sicherheitsfunktionen und -daten repräsentiert.
Das Identitätsmodul
unterstützt
unter anderem die Authentikation gegenüber einem Subskriptionsserver
(HSS, home subscriber service) des Heimatnetzwerks (HN) der Anwendereinheit.
Das Identitätsmodul
(ISIM) beinhaltet unter anderem eine (eindeutige und private) IMS-Identität (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 function)
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 Authentikationsdaten 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).
-
1 zeigt
anhand der linierten Pfeile diejenigen Verbindungen, die den Sicherheitsanforderungen
gegenüber
Angriffen Dritter genügen
müssen.
Es sind jeweils sogenannte Sicherheitsvereinbarungen (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 identity), 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/Authentikation 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 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 Proxy-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 Standby-Proxy-Server ersetzt, der dessen Position
im IMS übernimmt,
und auf dem die sicherheitsrelevanten Daten der Anwendungsschicht
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
Sicherheitsinformationen (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
ausgehandelten Sicherheitsvereinbarungen werden – soweit möglich – wieder hergestellt. Dazu
gehören
insbesondere die gemeinsamen Schlüssel, Verschlüsselungsalgorithmen,
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 ausschließ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 Sicherheitsvereinbarung.
-
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ählerstand 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 Betriebssystem 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 Tabelle 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 erfindungsgemäß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 Verbindung gelöscht
wird. Durch diese Ausgestaltung gelingt zumindest eine Reduzierung
der Angriffsmöglichkeiten.
-
Sicherheitsvereinbarungen
werden vorliegend als regulär
bezeichnet, wenn sie dem in 3GPP TS 33.203 (z.B. aktuelle Version
7.0.0 Rel. 7) insbesondere in Kapitel 7 spezifizierten Standardsatz
von Vereinbarungen entsprechen. Grundsätzlich 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 Sicherheitsvereinbarungen.
-
Grundsätzlich besteht
gemäß diesem
ersten Aspekt nach Wiederherstellung der ausgefallenen Sicherheitsvereinbarungen
die Möglichkeit,
anhand dieser SAs die laufende Verbindung zwischen 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 schränkt
vorhanden, weil die ursprünglich
im ersten Proxy-Server
(P-CSCF 1) bekannten Sequenznummern dem zweiten Proxy-Server (P-CSCF 2)
unbekannt sind und dieser daher nur mit groben Abschätzungen
rechnen kann.
-
Eine
weitergehende Ausführungsform
sieht daher vor, die reinstanzierten SAs nur temporär solange
einzusetzen, bis neu aufgestellte, auch bezüglich 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 temporären, 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 Re-Registrierung)
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 gesendet mit dem Ziel, die Serving-CSCF (S-CSCF)
anzutriggern, so dass diese die genannte Netzwerk-Re-Registrierung
anstöß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 (outbound 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
Request (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 erhalten 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 REGISTER-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 Registrierung, 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 Re-Registrierung
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 Proxy-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 dauerhaft 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 Ausfall 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 (Triggern) 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 Re-Registrierungen
der laufenden Session. Dies kann beispielsweise 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:
-
1:
den grundsätzlichen
Aufbau eines IMS-Systems gemäß 3GPP;
-
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.
-
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 1.
-
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 Anwendereinheit (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äß 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. Selectors, 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. 231 – 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 anders 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ähltem
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.
-
3 zeigt
die Fortsetzung des Flussdiagrams aus 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 vorhandene, 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) gefasst und geschützt (Integrity
und Encryption) gemäß den Vereinbarungen, 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) aufgrund 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 4 dargestellt, deren gezeigtes
Flussdiagramm sich an dasjenige aus 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
failover SA vorgegangen, was die Verschlüsselung betrifft. Die Anwendereinheit
(UE) entfernt infolgedessen die alte failover SA, so dass nur noch
die neue inbound fail-over SA verbleibt.
-
Somit
ist wieder die Situation hergestellt, die zu Anfang des Flussdiagramms
in 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.