-
Die
vorliegende Erfindung betrifft ein Verfahren zur Autorisierung von
Dienst- Anfragen
an Service Hosts in einem Netzwerk, wobei die Kommunikation innerhalb
des Netzwerks auf einem Routing-Mechanismus basiert, wonach Nutzerterminals innerhalb
des Netzwerks routbare Netzwerkadressen zugeordnet sind.
-
Verfahren
der hier in Rede stehenden Art sind seit geraumer Zeit in unterschiedlichen
Ausführungen
aus der Praxis bekannt. Die bekannten Autorisierungsverfahren beruhen
im Allgemeinen auf einer expliziten Sicherheitsassoziierung am Service Host,
beispielsweise in Form von Benutzer-Accounts, -Zertifikaten, oder
einer Oeffentlichen Schluessel Verwaltung (Public Key Infrastructure, PKI).
-
Insbesondere
im Hinblick auf netzwerkseitige Dienste, die zunehmend an Bedeutung
gewinnen, sind die bekannten Verfahren jedoch problematisch. Beispiele
für netzwerkseitige
Dienste, die spezielle Bearbeitungsmöglichkeiten nutzerseitiger
Datenflüsse
eröffnen,
sind Firewalls, NATs (Network Address Translators), Cashes, inteligente
Packetverarbeitungsknoten, Smart-Gateways oder programmierbare Router.
Während
Netzwerk-Administratoren z.B. basierend auf Nutzer-Authentifizierung
und Zugangskontrolle bereits über
sichere Mittel verfügen,
um diese netzwerkseitigen Dienste zu konfigurieren, steht Endnutzern
typischerweise keine explizite Sicherheitsassoziierung mit diesen
Diensten, z.B. ein Nutzer-Account
oder ein -Zertifikat, zur Verfügung.
Demzufolge ist es Endnutzern nicht möglich, die Vorteile der durch
netzwerkseitige Dienste bereitgestellten Möglichkeiten für sich,
d.h. für
den von ihnen ausgehenden sowie den an sie gerichteten Datenverkehr, zu
nutzen.
-
Der
vorliegenden Erfindung liegt nunmehr die Aufgabe zugrunde, ein Verfahren
der eingangs genannten Art anzugeben, das mit einfachen Mitteln, d.h.
insbesondere ohne die Notwendigkeit einer expliziten Sicherheitsassoziierung,
für viele
Arten von Diensten ein Maß an
Sicherheit bereitstellt, das Endnutzern die Nutzung der Dienste
ermöglicht.
-
Die
voranstehende Aufgabe ist durch ein Verfahren mit den Merkmalen
des Patentanspruchs 1 gelöst.
Danach ist das Verfahren derart ausgestaltet und weitergebildet,
dass der Service Host im Rahmen einer Request-Nachricht eine Nonce
an die Netzwerkadresse eines anfragenden Nutzerterminals schickt,
und dass das Nutzer terminal die Nonce oder einen sowohl seitens
des Service Hosts als auch seitens des Nutzerterminals von der Nonce
ableitbaren Wert im Rahmen einer Response-Nachricht an die Netzwerkadresse des
Service Host zurückschickt.
-
In
erfindungsgemäßer Weise
ist zunächst
erkannt worden, dass zur Autorisierung von Diensten, insbesondere
einer Vielzahl von netzwerkseitigen Diensten, die Validierung der
Netzwerkadresse eines anfragenden Benutzerterminals ein ausreichendes Maß an Sicherheit
bietet. In weiter erfindungsgemäßer Weise
wird im Hinblick auf die Validierung der Netzwerkadresse eines einen
Dienst anfragenden Nutzerterminals ein einfaches Request-Response-Protokoll
zwischen dem Service Host und dem anfragenden Nutzerterminal angegeben.
Dabei sendet der Service Host im Rahmen einer Request-Nachricht
eine Nonce an die Netzwerkadresse eines anfragenden Nutzerterminals.
Bei der Nonce kann es sich um einen beliebigen Wert handeln, beispielsweise
um eine ausreichend lange Zufallszahl, wobei lediglich sichergestellt
sein muss, dass es für einen
böswilligen
Nutzer nahezu ausgeschlossen ist, die Nonce zu erraten. Erfindungsgemäß schickt
das Nutzerterminal entweder die Nonce selbst oder einen sowohl seitens
des Service Hosts als auch seitens des Nutzerterminals von der Nonce
ableitbaren Wert im Rahmen einer Response-Nachricht an die Netzwerkadresse
des Service Hosts zurück.
Das erfindungsgemäße Verfahren
ermöglicht
somit die Validierung der Netzwerkadressen anfragender Nutzerterminals
und erlaubt es, böswillige
Nutzer, die unter einer fingierten Netzwerkadresse die Nutzung eines Dienstes
anfordern, zu erkennen.
-
Da
das erfindungsgemäße Request-Response-Protokoll
in ähnlicher
Weise verwendet wird wie bekannte standardmäßige „Challenge-Response-Protokolle", sei an dieser Stelle
ganz besonders hervorgehoben, dass das erfindungsgemäße Verfahren
nicht auf einem im Vorfeld festgelegten gemeinsamen Geheimnis (shared
secret) zwischen dem Nutzerterminal und dem Service Host beruht. Ein
derartiges festgesetztes Geheimnis ist zwingende Voraussetzung für die Funktionsweise
standardmäßiger Challenge-Response-Protokolle.
Bei dem erfindungsgemäßen Verfahren
ergibt sich die Sicherheit stattdessen aus den Routing-Eigenschaften
der Netzwerkumgebung, in der das Verfahren angewendet wird. Dabei
wird die Eigenschaft gerouteter Netzwerke ausgenutzt, dass die Request-Nachricht
nur an den Knoten (bzw. an das Sub-Netzwerk des Knotens) weitergeleitet
wird, zu dem die zu verifizierende Netzwerkadresse gehört.
-
Im
Hinblick auf die Art von Adressen, die verifiziert werden können, ist
das erfindungsgemäße Verfahren
in breitem Umfang anwendbar. Die einzige Voraussetzung besteht darin,
dass die Adressen innerhalb des Netzwerks geroutet werden müssen. So lassen
sich insbesondere Internet-Protokoll-Adressen verifizieren, d.h.
IPv4- oder IPv6-Adressen, sowie SIP URLs, die für Voice-over-IP Anwendungen verwendet
werden.
-
Das
erfindungsgemäße Verfahren
ermöglicht
Endnutzern, die Vorteile von netzwerkseitigen Diensten, die Mehrwert-Funktionalität innerhalb
des Netzwerks bereitstellen, für
ihre eigenen Datenflüsse,
d.h. für
Datenpakete, die an ihr bzw. von ihrem Nutzerterminal gesendet werden,
ohne einen expliziten Nutzer-Account auszunutzen. So können Nutzer beispielsweise
eine netzwerkseitige Firewall oder NAT-Middle-Box für ihre eigenen Datenflüsse konfigurieren
oder für
den Fall, dass ihr Nutzerterminal, beispielsweise für eine VoIP-Anwendung,
vom öffentlichen
Netzwerk erreichbar sein muss, eine Port-Adressen-Übersetzung
von einem NAT-Gateway
anfordern,.
-
Im
Rahmen einer konkreten Implementierung kann vorgesehen sein, dass
der Service Host den angefragten Dienst freigibt, wenn die zusammen mit
der Response-Nachricht
empfangene Nonce mit der gesendeten Nonce übereinstimmt. Mit anderen Worten
wird die Dienstanfrage nur bearbeitet, wenn das Nutzerterminal die
korrekte Nonce (oder einen davon abgeleiteten Wert) an die Netzwerkadresse des
Service Host zurückgeschickt
hat. Auf diese Weise ist es möglich,
einem böswilligen
Nutzer, der sich mittels einer falschen Netzwerkadresse als jemand anderes
ausgibt, den Zugang zu dem angeforderten Dienst zu verweigern. Anstelle
einer vollständigen Freigabe
des Dienstes kann in Abhängigkeit
von der Netzwerkadresse des anfragenden Nutzerterminals auch eine
Freigabe des Dienstes in einem begrenzten Umfang vorgenommen werden.
-
Für den Fall,
dass das Nutzerterminal eine Request-Nachricht von einem Service
Host empfängt,
ohne eine Dienstanfrage an den Service Host gesendet zu haben, kann
in vorteilhafter Weise vorgesehen sein, dass das Nutzerterminal
eine Negativ-Rückmeldung
an den Service-Host schickt. Auf diese Weise wird der Service-Host
auf bei der Validierung einer Netzwerkadresse aufgetretene Probleme aufmerksam gemacht,
und er kann die Bearbeitung der zugehörigen Dienst-Anfrage direkt
abbrechen.
-
In
Rahmen einer weiteren vorteilhaften Ausführungsform ist vorgesehen,
dass der Service Host nach Empfang einer gültigen Response-Nachricht eine
vorgebbare Zeitdauer abwartet, bevor er den angeforderten Dienst
freigibt. Dies bietet sich insbesondere für Broadcast-Medien an, wie
z.B. nicht-geswitchte Ethernet-Netzwerke, da ein böswilliger
Nutzer auf dem lokalen Broadcast-Medium hier in der Lage ist, den
lokalen Verkehr abzuhören.
Folglich kann er eine gültige
Response-Nachricht fälschen, obwohl
die Request-Nachricht an die korrekte Netzwerkadresse eines tatsächlich anfragenden
Nutzers geschickt worden ist. Im Falle eines derartigen Angriffs
empfängt
jedoch typischerweise auch der anfragende Nutzer die Request-Nachricht. Demzufolge kann
er die Wartezeit des Service Hosts bis zur Dienstfreigabe nutzen,
um einen Alarm, z.B. in Form einer Negativ-Bestätigung, an den Service Host
zu schicken. Es sei angemerkt, dass die Fälle, in denen Angriffe der
beschriebenen Art möglich
sind, aufgrund der Tatsache reduziert werden, dass sich die meisten „last-hop-link"-Technologien in
Richtung „non-broadcast"- bzw. geswitchter
Medien entwickeln (wie z.B. geswitchtes Ethernet, GPRS/UMTS, etc.).
-
Für den Fall,
dass der Service Host innerhalb einer vorgebbaren Zeitdauer keine
Response-Nachricht empfängt,
kann ebenfalls vorgesehen sein, dass die Bearbeitung der Dienst-Anfrage
abgebrochen wird.
-
Im
Hinblick auf ein höheres
Maß an
Sicherheit kann die im Rahmen der Request- und Response-Nachricht verwendete Nonce
um eine Hash-Kette erweitert werden. Auf diese Weise kann eine beweisbar
sichere Kommunikation zwischen dem Nutzerterminal und dem Service
Host realisiert werden, wodurch sich allerdings der zur Generierung der
Nachrichten erforderliche Bearbeitungsaufwand erhöht. Dies
bietet sich speziell an, wenn das selbe Nutzerterminal mehrere Service
Requests an den Service Host schickt. Damit wird die Zeit fuer eine
Attacke in Broadcastmedien reduziert, auf die Zeit des ersten Austauschs.
-
Im
Rahmen einer weiteren vorteilhaften Ausführungsform kann vorgesehen
sein, dass der Request-Nachricht und der Response-Nachricht eine Identifikation
(ID) zugeordnet wird. Dies bietet sich insbesondere für den Fall
an, dass in einer be stimmten Zeiteinheit eine Vielzahl von Dienst-Anfragen
an einen Service Host gerichtet wird. Mit Hilfe der ID kann dann
problemlos jeweils eine eindeutige Zuordnung einer ursprünglichen
Dienst-Anfrage zu einer Response-Antwort vorgenommen werden.
-
Es
gibt nun verschiedene Möglichkeiten,
die Lehre der vorliegenden Erfindung in vorteilhafter Weise auszugestalten
und weiterzubilden. Dazu ist einerseits auf die nachgeordneten Ansprüche, andererseits
auf die nachfolgende Erläuterung
bevorzugter Ausführungsbeispiele
des erfindungsgemäßen Verfahrens
zu verweisen. In Verbindung mit der Erläuterung der bevorzugten Ausführungsbeispiele
anhand der Zeichnung werden auch im Allgemeinen bevorzugte Ausgestaltungen
und Weiterbildung der Lehre erläutert.
In der Zeichnung zeigen
-
1 in
einem schematischen Diagramm ein Ausführungsbeispiel eines erfindungsgemäßen Verfahrens
zur Autorisierung von Dienst-Anfragen an einen Service Host,
-
2 in
einem schematischen Diagramm eine Situation, bei der eine Dienst-Anfrage von einem böswilligen
Nutzerterminal ausgesendet wird, und
-
3 in
einer schematischen Darstellung ein weiteres Ausführungsbeispiel
eines erfindungsgemäßen Verfahrens,
wobei sich die Dienst-Anfrage auf die Konfiguration einer netzwerkseitigen
Firewall bezieht.
-
1 zeigt
in einem Diagramm – schematisch – ein Ausführungsbeispiel
eines erfindungsgemäßen Verfahrens
zur Autorisierung von Dienst-Anfragen an Service Hosts in einem
Netzwerk. Nachdem der Service Host B eine Dienstanfrage vom Nutzerterminal
A erhalten hat, sendet der Service Host B eine Request-Nachricht
CReq{ID, X} an die Netzwerkadresse des Absenders, d.h. an die Netzwerkadresse
von Nutzerterminal A. Die Request-Nachricht CReq{ID, X} umfasst
eine Nonce X, wobei es sich dabei um einen beliebigen Wert handeln
kann, beispielsweise einen ausreichend langen Zufallswert. Im Hinblick
auf die Auswahl der Nonce X muss le diglich sichergestellt sein,
dass es einem böswilligen Nutzer
nahezu unmöglich
ist, die Nonce X zu erraten.
-
Durch
den Routing-Mechanismus des Netzwerks wird sichergestellt, dass
die Request-Nachricht CReq{ID, X} ausschließlich an das Sub-Netzwerk des
Nutzerterminals weitergeleitet wird, dem die zu verifizierende Netzwerkadresse
angehört.
Knoten/Terminals an irgendeinem anderen Sub-Netzwerk sind demzufolge
nicht in der Lage, diese Nachricht abzuhören.
-
Die
Response-Nachricht CRes{ID, X} von dem Nutzerterminal A, dessen
Netzwerkadresse verifiziert werden soll, umfasst ebenfalls die Nonce
X oder – alternativ – einen
anderen Wert, der sowohl vom Nutzerterminal A als auch vom Service
Host B von der Nonce X eindeutig ableitbar ist. Da die vom Service
Host B als Teil der Request-Nachricht CReq{ID, X} bereitgestellte
Nonce X so beschaffen ist, dass sie ein böswilliger Nutzer nicht erraten
kann, gibt es für
einen böswilligen
Nutzer keine Möglichkeit, eine
gültige
Response-Nachricht CRes{ID, X} zu fälschen. Wenn der Service Host
B eine gültige
Response-Nachricht CRes{ID, X} empfängt, weiß er demzufolge, dass die in
der ursprünglichen Dienst-Anfrage
enthaltene Netzwerkadresse gültig ist.
Folglich kann der angeforderte Dienst dem Nutzerterminal A freigegeben
werden.
-
Wie
ebenfalls in 1 illustriert, umfassen die
Request-Nachricht CReq{ID, X} und die Response-Nachricht CRes{ID,
X} zusätzlich
zu der Nonce X eine Identifikation ID. Diese wird benötigt, um die
Response-Nachricht CRes{ID, X} eindeutig der anfänglichen Dienst-Anfrage zuordnen
zu können. Die
Identifikation ID kann beispielsweise als Hash-Wert gebildet werden
oder von der Anwendingsnummer, oder von Nutzerterminal eigenen Nummerierung
von Requests.
-
In 2 ist
in einem schematischen Diagramm die Situation illustriert, in der
ein böswilliger Nutzer à eine
Dienst-Anfrage an Service Host B sendet und sich dabei als Nutzer
A ausgibt. Entsprechend dem erfindungsgemäßen Verfahren fordert der Service
Host B, der die Dienst-Anfrage empfängt, den Nutzer, der die Dienst-Anfrage gesendet
hat, zunächst
im Rahmen einer Request-Nachricht CReq{ID, X} auf, seine Netzwerkadresse
zu verifizieren. Da die Dienst-Anfrage allerdings von dem böswilligen
Nutzer à gefälscht worden
ist, hält
Service Host B Nutzer A für
den Absender der Dienst-Anfrage und sendet die Request-Nachricht
CReq{ID, X} somit an die Netzwerkadresse von Nutzer A. Nutzer A
weiß jedoch
nichts von einer Dienst-Anfrage und antwortet demzufolge mit einer
Negativ-Rückmeldung NACK{ID,
X}. Auf diese Weise wird der Service Host B über das Problem informiert,
und er kann die Bearbeitung der ursprünglichen Dienst-Anfrage abbrechen.
-
Es
sei angemerkt, dass das Verfahren auch derart ausgeführt werden
kann, dass selbst dann, wenn Nutzerterminal A keine Negativ-Rückmeldung NACK{ID,
X} an Service Host B sendet, die Bearbeitung der Dienst-Anfrage
durch Service Host B abgebrochen wird, wenn innerhalb einer vorgebbaren Zeitdauer
keine Response-Nachricht
CRes{ID, X} empfangen wird.
-
Das
in 2 dargestellte Beispiel verdeutlich noch einmal
ganz besonders, dass die Sicherheit des erfindungsgemäßen Verfahrens
nicht aus dem Request-Response-Protokoll
allein resultiert, sondern aus der Anwendung des Protokolls im Rahmen einer
gerouteten Netzwerkumgebung, in der durch ordnungsgemäßes Routing
garantiert ist, dass die Request-Nachricht CRes{ID, X} in korrekter
Weise und ausschließlich
an die zu validierende Netwerkadresse und/oder an das entsprechende
Sub-Netzwerk geschickt wird.
-
Es
sei des Weiteren angemerkt, dass ein böswilliger Nutzer, der auf dem
Datenpfad zwischen Nutzerterminal A und Service Host B sitzt, die
Request-Nachricht CReq{ID, X} leicht abhören kann. Demzufolge kann er
die korrespondierende Response-Nachricht CRes{ID, X} fälschen und
damit den Service Host B in den Glauben versetzen, dass die Netzwerkadresse
validiert worden sei. Aufgrund des Fehlens eines gemeinsamen Geheimnisses (shared
secret) zwischen dem Nutzerterminal und dem Service Host oder einer
zuverlässigen
PKI (Public Key Infrastructure) ist es nicht möglich, diese Art von Angriff
im Rahmen des erfindungsgemäßen Verfahrens
auszuschalten. Da das Zugangsnetzwerk jedoch typischerweise dem
Service-Provider „gehört", dem der Nutzer
in Bezug auf die Gewährleistung
einer sicheren Netzwerk-Infrastruktur ohnehin vertrauen muss, stellt
diese Art von Angriff im Allgemeinen keine größere Bedrohung dar.
-
Das
in 3 dargestellte Szenario zeigt ein weiteres Anwendungsbeispiel
des erfindungsgemäßen Verfahrens.
In dem dargestellten Beispiel wird ein mobiles Ter minal T entlastet,
indem es seine Firewall-Funktionalität oder einige Aspekte davon
auf eine netzwerkseitige Firewall FW überträgt, welche die Paket-Filterung
anstelle des mobilen Terminals T für dieses durchführt. Diese Übertragung
von Funktionalität
auf die netzwerkseitige Firewall FW ist in der Fig. durch den eingezeichneten
Pfeil angedeutet.
-
Zur
Sicherstellung, dass ein mobiles Terminal T auf einer netzwerkseitigen
Firewall FW nur diejenigen Firewall-Regeln konfigurieren kann, die
einen Einfluss auf den an dieses oder von diesem mobilen Terminal
T gesendeten Datenverkehr hat, wird zunächst die Netzwerkadresse des
mobilen Terminals T validiert. Dies geschieht entsprechend dem erfindungsgemäßen Verfahren,
wie es beispielhaft in Zusammenhang mit 1 erläutert worden
ist. Nach erfolgreicher Validierung der Netzwerkadresse des mobilen
Terminals T kann das Terminal T persönliche Firewall-Einstellungen ohne
die Notwendigkeit einer expliziten Sicherheitsassoziierung vornehmen.
-
Da
es bei dieser Anwendung nicht darauf ankommt, wer der tatsächliche
Nutzer ist, oder um wessen Terminal es sich handelt, besteht keine
Notwendigkeit einer expliziten Sicherheitsassoziierung zwischen
dem Nutzer/Nutzerterminal und dem Netzwerkprovider, der den Firewall-Service
betreibt. Das Erfordernis einer expliziten Sicherheitsassoziierung würde die
beschriebene Anwendung auf einer globalen Skala sogar nahezu unmöglich machen,
da eine vollständige
PKI erforderlich wäre,
die alle Dienste und alle mobilen Nutzer/Terminals umfasst.
-
Für mobile
Terminals ist der Zugang zu Diensten ohne explizite Sicherheitsassoziierung
insbesondere beim Roaming besonders nützlich. Während im Home-Netzwerk eines
Nutzers unter Umständen
eine vollständige
Sicherheitsassoziierung existiert, ist dies in fremden Netzwerken
im Allgemeinen nicht mehr der Fall. Dennoch kann der Nutzer mit Hilfe
des erfindungsgemäßen Verfahrens
einige netzwerkseitige Dienste nutzen.
-
Die
beschriebene Übertragung
von Firewall-Funktionalität
auf eine netzwerkseitige Firewall FW ist für das mobile Terminal T mit
einer Vielzahl von Vorteilen verbunden. So kann beispielsweise die Datenlast
auf dem drahtlosen Link L erheblich reduziert werden, da unerwünschter
Verkehr bereits im Netzwerk blockiert werden kann. Darüber hinaus wird
die Betriebsdauer des – batteriebetriebenen – mobilen
Terminals T verlängert,
da kein unerwünschter
Verkehr empfangen und verarbeitet werden muss. Mit anderen Worten
kann die Zeitdauer, in der sich das mobile Terminal T in einem Energiesparmodus befinden
kann, verlängert
werden. Darüber
hinaus kann auch die Bearbeitungs- und/oder Speicherkapazität des Terminals
T reduziert werden, wenn die Firewall-Funktionalität nicht
lokal, sondern bereits im Netzwerk ausgeführt wird. Schließlich können auch DoS-Angriffe
(Denial of Service) verhindert werden, da unerwünschte Pakete bereits verworfen
werden können,
bevor sie den drahtlosen Link L erreichen. Insgesamt wird somit
die drahtlose Bandbreite nicht unnötig belastet.
-
Schließlich sei
ausdrücklich
darauf hingewiesen, dass die voranstehend beschriebenen Ausführungsbeispiele
lediglich zur Erörterung
der beanspruchten Lehre dienen, diese jedoch nicht auf die Ausführungsbeispiele
einschränken.