DE10297253T5 - Adressiermechanismus in Mobile-IP - Google Patents

Adressiermechanismus in Mobile-IP Download PDF

Info

Publication number
DE10297253T5
DE10297253T5 DE10297253T DE10297253T DE10297253T5 DE 10297253 T5 DE10297253 T5 DE 10297253T5 DE 10297253 T DE10297253 T DE 10297253T DE 10297253 T DE10297253 T DE 10297253T DE 10297253 T5 DE10297253 T5 DE 10297253T5
Authority
DE
Germany
Prior art keywords
node
address
public
private key
client terminal
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
DE10297253T
Other languages
English (en)
Inventor
Jukka Ylitalo
Pekka Nikander
Jari Arkko
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of DE10297253T5 publication Critical patent/DE10297253T5/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • 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/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption

Abstract

Verfahren zum Übertragen von Verantwortung für eine im Besitz eines ersten IP-Netzknotenpunktes stehende IP-Adresse zu einem zweiten IP-Netzknotenpunkt, bei dem zumindest ein Teil der IP-Adresse von einem öffentlichen Schlüssel und einem öffentlichen/privaten Schlüsselpaar ableitbar ist, welches Schlüsselpaar zu dem ersten Knotenpunkt gehört, wobei das Verfahren folgendes aufweist:
Benachrichtigen des ersten Knotenpunktes hinsichtlich eines öffentlichen Schlüssels eines öffentlich/privaten Schlüsselpaares, das zu dem zweiten Knotenpunkt gehört;
Signieren des öffentlichen Schlüssels des zweiten Knotenpunktes mit dem privaten Schlüssel des ersten Knotenpunktes beim ersten Knotenpunkt, um ein Autorisierungszertifikat bereitzustellen; und
Versenden des Autorisierungszertifikats von dem ersten Knotenpunkt zu dem zweiten Knotenpunkt,
wobei das Autorisierungszertifikat anschließend in Nachrichten, die zu der IP-Adresse gehören, eingefügt und mit dem privaten Schlüssel des zweiten Knotenpunktes signiert wird, von dem zweiten Knotenpunkt zu Empfänger-Knotenpunkten versendet wird, und von den Empfänger-Knotenpunkten verwendet wird, um den Anspruch des zweiten Knotenpunktes auf die IP-Adresse zu verifizieren.

Description

  • Fachgebiet der Erfindung
  • Die vorliegende Erfindung betrifft Adressiermechanismen in Mobile-IP und im Einzelnen Adressiermechanismen, die es IP-Netzknoten gestatten, zu prüfen, dass sie autorisiert sind, Information hinsichtlich einer einem anderen Netzwerkknoten zugehörigen IP-Adresse zu verändern oder zu aktualisieren.
  • Hintergrund der Erfindung
  • Das gewaltige Wachstum bei der Verwendung des Internets hat Schwächen und Einschränkungen des gegenwärtigen, als IPv4 bekannten Internetprotokolls an den Tag gelegt. Die Internet Engineering Task Force (IETF), welches eine sich selbst verwaltende Verbindung von interessierten bzw. betroffenen Parteien ist, entwickelt von daher ein verbessertes Internetprotokoll, welches als IPv6 bekannt ist. IPv6 bezieht einen wesentlich verbesserten Sicherheitsmechanismus, der als IPSec bekannt ist (welcher zwei oder mehrere Parteien in die Lage versetzt, auf sichere Weise über das Internet zu kommunizieren), sowie Bereitstellungen für einen mobilen Internetzugriff (Mobile-IP) ein. Mobile-IP gestattet es, dass ein Benutzer in Bewegung auf das Internet zugreift, und zwar indem von einem IP-Zugriffsknoten zu einem anderen geroamt bzw. gewandert wird. Mobile-IP wird im Einzelnen von solchen Benutzern verwendet, die über drahtlose Mobilvorrichtungen auf das Internet zugreifen (die beispielsweise mit Wireless-LANs und zellularen Telefonnetzen verbunden sind).
  • IPv6 stellt einen wesentlich größeren IP-Adressenraum bereit, und zwar indem IP-Adressen von 128 Bit-Längen bereitgestellt werden. Die ersten 64 Bits einer Adresse bilden einen Routing-Prefix bzw. eine Leitweglenkungs-Vorwahl aus, der bzw. die jenen Internetzugriffspunkt (oder den sogenannten "lokalen Link bzw. Verbindung") eindeutig identifiziert, der von einem IP-Terminal oder einem Host (übergeordnete Datenverarbeitungsanlage) verwendet wird, während die letzten 64 Bits einen Host-Suffix ausbilden, der eindeutig das mobile Terminal zu dem Zugriffsknoten (oder innerhalb des lokalen Links) identifiziert. Der Host-Suffix wird als ein "Schnittstellen-Identifizierer" bezeichnet, da er den Host über die Zugriffs-Schnittstelle eindeutig identifiziert. Wenn ein Host in das Bewusstsein eines Zugriffsknotens eindringt, lernt in typischer Weise der Host den Routing-Prefix des Zugriffsknotens anhand einer Ankündigungsnachricht, die von dem Zugriffsknoten versendet wird. Gemäß RFC3041 (IETF) erzeugt dann ein Host seinen Schnittstellen-Identifizierer, und zwar unter Verwendung einer mittels des Hosts erzeugten Zufallszahl. Der Host kann zusätzlich eine Adresse einer Sicherungsschicht oder Verbindungsschicht verwenden, um den Schnittstellen-Identifizierer zu erzeugen, wobei die Adresse der Sicherungsschicht oder der Verbindungsschicht beispielsweise eine von dem Zugriffsnetz verwendete MAC-Schicht-Adresse ist.
  • Wie bereits erwähnt, gestattet Mobile-IP, dass sich Hosts bzw. übergeordnete Datenverarbeitungsanlagen zwischen Zugriffsknoten und sogar Zugriffsnetzen bewegen bzw. roamen, ein Merkmal, welches es erfordert, dass es Hosts bzw. übergeordneten Datenverarbeitungsanlagen gestattet ist, die IP-Adressen zu ändern, welche ihre gegenwärtigen physikalischen Standorte definieren. In typischer Weise ist einem mobilen Host in einem Heimatnetz eine "festgelegte" Heimat-IP-Adresse zugeordnet. Wenn der Host zu Hause ist, kann er diese Heimat-Adresse als seine physikalische Adresse verwenden. Wenn sich jedoch ein Host selbst an einen "fremden" Zugriffsknoten anschließt, wird dem Host eine temporäre "Care-of-Adresse" zugeordnet. Hosts, die dem mobilen Host entsprechen, behalten einen Binding-Cache bzw. Bindungs-Cache bei, der Mappings bzw. Zuweisungen zwischen Heimat-Adressen und Care-of-Adressen enthält. Für eintreffende Pakete tauscht die Mobile-IP-Schicht bei einem entsprechenden Host die Care-of-Adresse für die Heimat-Adresse in dem Zielfeld aus, während für abgehende Pakete die Mobile-IP-Schicht bei einem entsprechenden Host die Heimat-Adresse mit der Care-of-Adresse in dem Ziel-Adressenfeld austauscht. Wenn ein Mobile-Host eine neue Care-of-Adresse erhält, muss er eine Bindungs-Aktualisierungsnachricht zu sämtlichen entsprechenden Hosts versenden, um ihre Bindungs-Caches bzw. Bindungs-Caches zu aktualisieren (von daher wird sichergestellt, dass nachfolgende Datagramme zu der richtigen Care-of-Adresse versendet werden). Ein Mobile-IP-Szenario ist in 1 dargestellt.
  • Bei diesem Mechanismus liegt ein potentielles Risiko darin, dass eine bösartige dritte Partei in der Lage sein kann, eine gefälschte Bindungs-Aktualisierung zu einem entsprechenden Host zu versenden, um zu bewirken, dass Datenpakete, die für einen Mobile-Host beabsichtigt sind, zu der bösartigen Partei geroutet bzw. leitweggelenkt werden. Wenn die Pakete dann durch die bösartige Partei zu dem Mobile-Host weitergeleitet werden (nachdem sie von dieser Partei geöffnet und gelesen wurden), mag der Mobile-Host noch nicht einmal wissen, dass seine Pakete umgeleitet und gelesen wurden. Dieses Problem ist nicht auf Mobile-IP beschränkt, sondern ist ebenso in anderen Signalisierungsfunktionen innerhalb der IPv6-Architektur vorhanden. Das mit Mobile-IP zusammenhängende Problem und einige andere Probleme werden detaillierter in dem IETF-Vortrag "draft-nikander-ipng-address-ownership-00.txt" vom Februar 2001 beschrieben.
  • Eine Lösung für dieses Problem wurde in dem IETF-Vortrag "draft-bradner-pbk-frame.00.txt" vom Februar 2001 vorgeschlagen. Diese Lösung bezieht das Erzeugen eines eingebauten Verwendungszweck-Schlüssel- (purpose built key) (PBK)-Paares bei dem Mobile-Host ein, wobei das Schlüsselpaar einen öffentlichen und einen privaten Schlüssel enthält. Es wird eine Endpunkt-ID (EID) bei dem Mobile-Host erzeugt, und zwar indem eine Hash-Summe bzw. eine Prüfsumme an dem öffentlichen Schlüssel angewandt wird. Die EID wird zu einem entsprechenden Host versendet, und zwar sobald eine IP-Verbindung initiiert wurde. Anschließend sendet der Mobile-Host den öffentlichen Schlüssel zu dem entsprechenden Host. Der entsprechende Host ist in der Lage, zu verifizieren, dass der öffentliche Schlüssel zu der Verbindung "gehört", und zwar indem die Ein-Wege-Codierfunktion an dem Schlüssel angewandt und das Ergebnis mit der zuvor empfangenden EID verglichen wird. Jedwede Bindungs-Aktualisierung, die anschließend versendet wird, wird bei dem Mobile-Host mit dem privaten Schlüssels des Hosts signiert. Der entsprechende Host verifiziert die an die Bindungs-Aktualisierung angehängte Signatur, und zwar indem der zuvor empfangende öffentliche Schlüssel verwendet wird. Verbesserte Lösungen, die eine höhere Sicherheit bieten, werden in den folgenden Literaturstellen beschrieben: P. Nikander, <draft-nikander-ipng-pbk-addresses.00.txt>, Ericsson Nomadiclab, März 2001, "A Scaleable Architecture for IPv6 Address Ownership"; G. Montenegro,C. Castelluccia, 20. Juli 2001, SUCV Identifiers and Addresses, Internet Draft (Work in Progress); und M. Roe, Microsoft, August 2001, "Authentication of Mobile-IPv6 Binding Updates and Acknowledgements", Internet Draft (Work In Progress), http://www.ietf.org/internet-drafts/draft-roe-Mobile-IP-updateauth.00txt.
  • Zusammenfassung der vorliegenden Erfindung
  • Die in den vorangehenden Absätzen bezeichneten Lösungen können nur den Fall behandeln, wo der Besitzer der Adresse die Bindungs-Aktualisierung versendet. Jedoch gibt es einige Situationen, bei denen es für andere Knotenpunkte notwendig ist, diese Bekanntgabe bzw. Bekanntmachungen im Namen von dem echten Besitzer zu versenden. Beispielsweise sind DHCP-Server, die einen Adressenpool verwalten, im Besitz von Adressen, sie würden es jedoch ebenso den Benutzern von diesen Adressen gestatten, von der Mobilität Nutzen zu ziehen (siehe 2). Ebenso könnte ein Knotenpunkt hinter einem mobilen Router bzw. Kommunikations-Server liegen, und würde es erfordern, dass die Bindungs-Aktualisierung, die zu diesem Router bzw. Kommunikations-Server gesendet wird, übertragen wird, und zwar auch dann, wenn die tatsächliche Adresse im Besitz von dem Knotenpunkt selbst ist (3, wo ein mobiler Knotenpunkt MN sich von einem ersten Zugriffs-Router bzw. Kommunikations-Server AR#1 zu einem zweiten Zugriffs-Router bzw. Kommunikations-Server AR#2) bewegt hat.
  • Die Gemeinsamkeit bei den beschriebenen Situationen ist darin zu sehen, dass die Übertragung der Verantwortung für die IP-Adresse beschränkt und konditional bzw. bedingt ist. Einem Router bzw. Kommunikations-Server ist es nicht gestattet, Bindungs-Aktualisierungen zu versenden, nachdem sich ein Knotenpunkt aus dem von dem Router bzw. Kommunikations-Server gesteuerten Netzwerk heraus bewegt hat. Der DHCP-Server gestattet es einem Knotenpunkt nicht, eine Bindungs-Aktualisierung hinsichtlich einer vorgegebenen Adresse zu versenden, nachdem diese Adresse von dem Knotenpunkt freigegeben und zu einem anderen Knotenpunkt übergeben wurde.
  • Gemäß einem ersten Aspekt der vorliegenden Erfindung wird ein Verfahren zum Übertragen von Verantwortung für eine im Besitz. eines ersten IP-Netzknotenpunktes stehende IP-Adresse zu einem zweiten IP-Netzknotenpunkt angegeben, wobei zumindest ein Teil der IP-Adresse von einem öffentlichen Schlüssel und einem öffentlichen/privaten Schlüsselpaar ableitbar ist, welches Schlüsselpaar zu dem ersten Knotenpunkt gehört, wobei das Verfahren folgendes aufweist:
    Benachrichtigen des ersten Knotenpunktes hinsichtlich eines öffentlichen Schlüssels eines öffentlich/privaten Schlüsselpaares, das zu dem zweiten Knotenpunkt gehört;
    beim ersten Knotenpunkt: Signieren des öffentlichen Schlüssels des zweiten Knotenpunktes mit dem privaten Schlüssel des ersten Knotenpunktes, um ein Autorisierungszertifikat bereitzustellen; und
    Versenden des Autorisierungszertifikats von dem ersten Knotenpunkt zu dem zweiten Knotenpunkt,
    wobei das Autorisierungszertifikat anschließend in Nachrichten, die zu der IP-Adresse gehören, eingefügt und mit dem privaten Schlüssel des zweiten Knotenpunktes signiert wird, von dem zweiten Knotenpunkt zu Empfänger-Knotenpunkten versendet wird, und von den Empfänger-Knotenpunkten verwendet wird, um den Anspruch des zweiten Knotenpunktes auf die IP-Adresse zu verifizieren.
  • In einer Ausführungsform der vorliegenden Erfindung ist der erste IP-Netzknotenpunkt ein DHCP-Server, und der zweite IP-Netzknotenpunkt ist ein Client-Knotenpunkt, beispielsweise ein mobiles Terminal (z.B. ein Mobil-Telefon, PDA, ein Kommunikator, ein Palmtop-Computer oder ein Laptop-Computer) oder ein PC. Der Client-Knotenpunkt kann mit einem IP-Netz über eine feststehende Leitung oder eine drahtlose Verbindung verbunden sein. In einer zweiten Ausführungsform der Erfindung ist der erste IP-Netzknotenpunkt ein Client-Knotenpunkt, und der zweite IP-Netzknotenpunkt ist ein mobiler Router bzw. Kommunikations-Server.
  • In bevorzugter Weise ist ein Schnittstellen-Identifizierer-Teil der IP-Adresse von dem öffentlichen Schlüssel des öffentlichen/privaten Schlüsselpaares, welches zu dem. ersten Knotenpunkt gehört, ableitbar, und zwar indem beispielsweise eine Ein-Wege-Funktion an diesem öffentlichen Schlüssel angewandt wird.
  • In bevorzugter Weise ermöglicht das Verfahren der vorliegenden Erfindung das Versenden von Bindungs-Aktualisierungs-Nachrichten gemäß dem Mobile-IP-Protokoll durch den zweiten Knotenpunkt hinsichtlich der IP-Adresse. Solche Bindungs-Aktualisierungs-Nachrichten enthalten das Autorisierungs-Zertifikat, die IP-Adresse und eine neue Care-of-Adresse. Das Zertifikat kann den öffentlichen Schlüssel des ersten Knotenpunktes enthalten, und welcher erforderlich ist, um das Zertifikat zu authentisieren.
  • Das Zertifikat kann abgeleitet werden, indem eine Kombination des öffentlichen Schlüssels des zweiten Knotenpunktes (oder des Absender-Knotenpunktes) und ein Zeit-Kennzeichen mit dem privaten Schlüssel des ersten Knotenpunktes (oder des Besitzer-Knotenpunktes) signiert wird, wobei das Zeit-Kennzeichen jene Zeit ist, bei welcher die Autorisierung bzw. Ermächtigung zur Verwendung der IP-Adresse erlöscht.
  • Gemäß einem zweiten Aspekt der vorliegenden Erfindung wird ein Verfahren zum Authentifizieren einer Nachricht bereitgestellt, welche bei einem Empfänger-Knotenpunkt eines IP-Netzes von einem Absender-Knotenpunkt empfangen wird, wobei die Nachricht zu einer IP-Adresse gehört und folgendes aufweist:
    die IP-Adresse,
    einen öffentlichen Schlüssel von einem öffentlichen/privaten Schlüsselpaar, das zu dem Knotenpunkt gehört, welcher in Besitz der IP-Adresse ist, und
    ein Zertifikat, welches von dem Besitzer-Knotenpunkt an den Absender-Knotenpunkt ausgegeben wird, und welches abgeleitet wird, indem der öffentliche Schlüssel eines öffentlichen/privaten Schlüsselpaares, das zu dem Absender-Knotenpunkt gehört, mit dem privaten Schlüssel des Besitzer-Knotenpunktes signiert wird,
    wobei die Nachricht mit dem privaten Schlüssel des Absender-Knotenpunktes signiert wird, wobei das Verfahren folgendes aufweist:
    Bestätigen, dass zumindest Teil der IP-Adresse von dem öffentlichen Schlüssel des Besitzer-Knotenpunktes ableitbar ist;
    Bestätigen, dass das Zertifikat mit dem privaten Schlüssel des Besitzer-Knotenpunktes signiert ist; und
    Bestätigen, dass die Nachricht mit dem privaten Schlüssel des Absender-Knotenpunktes signiert ist.
  • Wenn das Zertifikat abgeleitet wird, indem sowohl der öffentliche Schlüssel des öffentlichen/privaten Schlüsselpaares, das zu dem Absender-Knotenpunkt gehört, als auch ein Zeit-Kennzeichen signiert werden, kann der Empfänger-Knotenpunkt bestätigen, dass das Zeit-Kennzeichen nicht vor dem Wirken an der Nachricht erloschen bzw. ausgelaufen ist.
  • Gemäß einem dritten Aspekt der vorliegenden Erfindung wird ein IP-Client-Terminal bereitgestellt, welches ausgelegt ist, eine IP-Adresse im Betrieb von einem anderen IP-Netzknotenpunkt zu mieten bzw. zu leasen, wobei zumindest ein Teil der IP-Adresse von einem öffentlichen Schlüssel eines öffentlichen/privaten Schlüsselpaares, das zu dem Besitzer-Knotenpunkt gehört, ableitbar ist, wobei das Client-Terminal folgendes aufweist:
    eine Einrichtung zum Benachrichtigen des Besitzer-Knotenpunktes hinsichtlich eines öffentlichen Schlüssels eines öffentlichen/privaten Schlüsselpaares, welches zu dem Client-Terminal gehört;
    eine Einrichtung zum Empfangen eines Autorisierungszertifikates von dem Besitzer-Knotenpunkt, welches den öffentlichen Schlüssel des Client-Terminals enthält, der mit dem privaten Schlüssel des Besitzer-Knotenpunktes signiert ist;
    wobei das Autorisierungszertifikat anschließend in Nachrichten, die zu der IP-Adresse gehören, eingefügt und mit dem privaten Schlüssel des Client-Terminals signiert wird, von dem Client-Terminal zu Empfänger-Knotenpunkten versendet wird, und von den Empfänger-Knotenpunkten verwendet wird, um den Anspruch des Client-Terminals auf die IP-Adresse zu verifizieren.
  • Gemäß einem vierten Aspekt der vorliegenden Erfindung wird ein IP-Client-Terminal bereitgestellt, welches ausgelegt ist, im Betrieb einen bevollmächtigten IP-Netzknotenpunkt zu autorisieren, eine im Besitz von dem Client-Terminal stehende IP-Adresse zu verwenden, wobei zumindest ein Teil der IP-Adresse von einem öffentlichen Schlüssel eines öffentlichen/privaten Schlüsselpaares ableitbar ist, welches zu dem Client-Terminal gehört, wobei das Client-Terminal folgendes aufweist:
    eine Einrichtung zum Empfangen von dem bevollmächtigten Knotenpunkt eines öffentlichen Schlüssels eines öffentlichen/privaten Schlüsselpaares, welches zu dem bevollmächtigten Knotenpunkt gehört;
    eine Einrichtung zum Erzeugen eines Autorisationszertifikats, das den mit dem privaten Schlüssel des Client-Terminals signierten öffentlichen Schlüssel des bevollmächtigten Knotenpunktes enthält, und zum Versenden des Zertifikates zu dem bevollmächtigten Knotenpunkt;
    wobei das Autorisationszertifikat anschließend in Nachrichten, die zu der IP-Adresse gehören, eingefügt und mit dem privaten Schlüssel des bevollmächtigten Knotenpunktes signiert wird, von dem bevollmächtigten Knotenpunkt zu Empfänger-Knotenpunkten versendet wird, und von den Empfänger-Knotenpunkten verwendet wird, um den Anspruch des bevollmächtigten Knotenpunktes auf die IP-Adresse zu verifizieren.
  • Gemäß einem fünften Aspekt der vorliegenden Erfindung wird ein IP-Server angegeben, der ausgelegt ist, im Betrieb einen Client-IP-Knotenpunkt dahingehend zu autorisieren, eine im Besitz des Servers stehende IP-Adresse zu verwenden, wobei zumindest ein Teil der IP-Adresse von einem öffentlichen Schlüssel eines öffentlichen/privaten Schlüsselpaares ableitbar ist, das zu dem Server gehört, wobei der Server folgendes aufweist:
    eine Einrichtung zum Empfangen von dem Client-Terminal eines öffentlichen Schlüssels eines öffentlichen/privaten Schlüsselpaares, das zu dem Client-Terminal gehört;
    eine Einrichtung zum Erzeugen eines Autorisationszertifikats, das den mit dem privaten Schlüssel des Servers signierten öffentlichen Schlüssel des Client-Terminals enthält, und zum Versenden des Zertifikats zu dem Client-Terminal;
    wobei das Autorisationszertifikat anschließend in Nachrichten, die zu der IP-Adresse gehören, eingefügt und mit dem privaten Schlüssel des Client-Terminals signiert wird, von dem Client-Terminal zu Empfänger-Knotenpunkten versendet wird, und von den Empfänger-Knotenpunkten verwendet wird, um den Anspruch des Client-Terminals auf die IP-Adresse zu verifizieren.
  • Gemäß einem sechsten Aspekt der vorliegenden Erfindung wird ein IP-Server angegeben, der ausgelegt ist, im Betrieb Verantwortung für eine IP-Adresse zu übernehmen, die in Besitz von einem Client-Terminal steht, wobei zumindest ein Teil der IP-Adresse von einem öffentlichen Schlüssel eines öffentlichen/privaten Schlüsselpaares ableitbar ist, das zu dem Client-Terminal gehört, wobei der Server folgendes aufweist:
    eine Einrichtung zum Versenden zu dem Client-Terminal eines öffentlichen Schlüssels von einem öffentlichen/privaten Schlüsselpaar, das zu dem Server gehört;
    eine Einrichtung zum Empfangen von dem Client-Terminal eines Autorisationszertifikats, das den mit dem privaten Schlüssel des Client-Terminals signierten öffentlichen Schlüssel des Servers enthält;
    wobei das Autorisationszertifikat anschließend in Nachrichten, die zu der IP-Adresse gehören, eingefügt und mit dem privaten Schlüssel des Servers signiert wird, von dem Server zu Empfänger-Knotenpunkten versendet wird, und von dem Empfänger-Knotenpunkten verwendet wird, um den Anspruch des Servers auf die IP-Adresse zu verifizieren.
  • Kurze Beschreibung der Zeichnungen
  • 1 zeigt schematisch die Prinzipien der Mobile-IP-Leitwegelenkung;
  • 2 zeigt schematisch die Prinzipien der Mobile-IP-Leitweglenkung, wenn eine IP-Adresse im Besitz eines DHCP-Servers steht und von einem DHCP-Server belegt wird; und
  • 3 zeigt schematisch die Prinzipien der Mobile-IP-Leitweglenkung, wenn ein mobiler Knotenpunkt hinter einem mobilen Router bzw. Kommunikations-Server angeordnet ist.
  • 4 ist ein Signalisierungsdiagramm, das die Signalisierung zwischen einem mobilen Knotenpunkt, einem DHCP-Server und einem entsprechenden Knotenpunkt zeigt; und
  • 5 ist ein Signalisierungsdiagramm, das die Signalisierung zwischen einem mobilen Knotenpunkt, einem mobilen Router bzw. Kommunikations-Server und einem entsprechenden Knotenpunkt zeigt.
    •
  • Detaillierte Beschreibung von bestimmten Ausführungsformen
  • Zum Zwecke der nachfolgenden Beispiele wird angenommen, dass ein IP-Netzknotenpunkt, der im Besitz einer IP-Adresse ist, über ein öffentlich/privates Schlüsselpaar verfügt, wobei P den öffentlichen Schlüssel bezeichnet, und S den privaten oder Sicherheitsschlüssel bezeichnet. Der Knotenpunkt erzeugt die IP-Adresse, indem der Algorithmus A = R:h(P) verwendet wird, wobei R irgendein Leitweglenkungs-Prefix ist, der zu dem Knotenpunkt selbst gehören kann, oder der bei dem Knotenpunkt von irgendeinem anderen Knotenpunkt (beispielsweise einem Zugriffs-Knotenpunkt) empfangen werden kann. Die Funktion h ist irgendeine Ein-Wege-Funktion, wie etwa eine kryptografische Hash-Funktion bzw. Prüfsummenfunktion. Wenn der Knotenpunkt (, der im Besitz der IP-Adresse ist) zu einem entsprechenden Knotenpunkt gemäß dem Mobile-IP-Protokoll eine Bindungs-Aktualisierung versendet, enthält diese in der Nachricht seinen öffentlichen Schlüssel P. Der Absender-Knotenpunkt erzeugt zusätzlich eine Signatur, indem irgendeine umkehrbare kryptografische Funktion und der Sicherheitsschlüssel S an den Inhalten der Nachricht angewandt wird, und fügt die Signatur zu der Nachricht hinzu.
  • Wenn der entsprechende Knotenpunkt die Bindungs-Aktualisierung empfängt, verifiziert er zunächst, dass die Signatur richtig ist, indem die umkehrbare kryptografische Funktion und der in der Nachricht enthaltene öffentliche Schlüssel P an der Signatur angewandt werden. Unter der Annahme, dass das Ergebnis dem Inhalt der Nachricht entspricht, und dass von daher der entsprechende Knotenpunkt verifiziert, dass der Absender-Knotenpunkt in Besitz des beanspruchten öffentlichen Schlüssels S ist, wendet der entsprechende Knotenpunkt die Ein-Wege-Funktion h an dem öffentlichen Schlüssel an, um zu bestätigen, dass der Host-Teil der Quell-IP-Adresse von dem Besitzer des Schlüsselpaares (P, S) erzeugt wurde. Während es für einen Angreifer möglich ist, durch sämtliche mögliche Schlüsselpaare (P, S) hindurchzugehen, indem er versucht, ein Schlüsselpaar aufzufinden, welches den gleichen Wert von h(P) erzeugen wird, müsste in Anbetracht der Tatsache, dass das Bit-Feld, welches verwendet wird, um h(P) in Ipv6 zu speichern, sehr groß ist (62 Bits), ein enormer Arbeitsaufwand durchgeführt werden, um dieses zu erzielen.
  • DHCP-Server verwalten einen Pool von IP-Adressen, die sie besitzen, und sie "leasen" bzw. "vermieten" diese. Adressen temporär an Client-Knotenpunkten, wie etwa PCs, die an ein bestimmtes Netzwerk angeschlossen sind. Indem die obigen Betrachtungen an dieses Szenario (das in 2 dargestellt ist) angewandt wird, wird es der DHCP-Server sein, der die öffentlichen/privaten Schlüsselpaare (P, S) besitzt, die verwendet werden, um entsprechende IP-Adressen zu erzeugen.
  • Um es einem Client-Knotenpunkt hinter einem DHCP-Server zu gestatten, die Mobilität und Bindungs-Aktualisierungen zu verwenden, kommt das Nachfolgende der Prozedur zum Einsatz:
    • 1. Der Client und der DHCP-Server einigen sich darauf, dass eine bestimmte Adresse von dem Client für eine bestimmte Zeitdauer gemietet wird. Die Adresse A enthält einen Schnittstellen-Identifizierer-Teil, der zu dem Schlüsselpaar (P, S) gehört, welches in Besitz des DHCP steht, d.h. A = R:h(P).
    • 2. Der Client kann optional während dieses Prozesses authentisiert sein.
    • 3. Der Client ist im Besitz eines öffentlichen/privaten Schlüsselpaares (Pcl, Scl) und gibt seinen öffentlichen Schlüssel Pcl während dieses Prozesses zu dem DHCP- Server. Das öffentliche/private Schlüsselpaar mag nur für diesen Zweck erzeugt worden sein, oder er mag permanent dem Client zugewiesen sein.
    • 4. Der DHCP-Server bringt ein Zertifikat für Pcl hervor, um die Adresse wahrzunehmen, die in Beziehung zu P steht. Das heißt, der Server signiert das Tuple [Pcl, Endzeit mit seinem privaten Schlüssel S, wobei die Endzeit jene Zeit identifiziert, bei der die zugeordnete IP-Adresse ausläuft. Das Zertifikat, welches P und die Signatur enthält, wird zu dem Client gesendet.
    • 5. Wenn der Client-Knotenpunkt es wünscht, eine Bindungs-Aktualisierung an irgendeinen entsprechenden Knotenpunkt zu versenden, signiert er die Anforderung mit seinem privaten Schlüssel Scl und fügt das Zertifikat (welches im Schritt 4 hervorgebracht wurde) an die Nachricht an.
    • 6. Der Knotenpunkt, der die Bindungs-Aktualisierung empfängt, verifiziert zunächst, dass der Wert des Schnittstellen-Identifizierer-Teils der IP-Adresse des Absenders in Beziehung zu dem öffentlichen Schlüssel P steht, und zwar indem die Ein-Wege-Funktion h, die dem entsprechenden Knotenpunkt bekannt ist, an den öffentlichen Schlüssel P angewandt wird. Der Empfänger-Knotenpunkt verwendet dann den öffentlichen Schlüssel P des DHCP, um zu verifizieren, dass das Zertifikat richtig mit dem entsprechenden Sicherheitsschlüssel S signiert ist, und stellt den öffentlichen Schlüssel Pcl und die gültige Endzeit wieder her. Unter der Annahme, dass die Endzeit nicht abgelaufen ist, verifiziert der Empfänger-Knotenpunkt, dass die Signatur in der Bindungs-Aktualisierung mit dem privaten Schlüssel Scl erzeugt wurde, der zu dem in dem Zertifikat enthaltenen öffentlichen Schlüssel Pcl gehört, wodurch überprüft wird, dass der Absender-Knotenpunkt in Besitz des öffentlichen Schlüssels Pcl ist. Der Empfänger-Knotenpunkt aktualisiert dann seinen Bindungs-Cache mit der neuen Care-of-Adresse.
  • Die Prozedur kann mit dem nachfolgenden Signalisierungsablauf dargestellt werden, der in 4 dargestellt ist:
    • 1. Client-Server: Anfrage; Zeitdauer = T, öffentlicher Client-Schlüssel = Pcl
    • 2. Server-Client: Antwort bzw. Erwiderung; Adresse = A, Zertifikat = P, {[Pcl, Endzeit] signiert mit S}
    • 3. vom Client verschiedener Knotenpunkt: Bindungs-Aktualisierung; Care-of-Adresse, Adresse = A, Zertifikat, Signatur an der gesamten Nachricht mit Scl.
  • Manchmal können Knotenpunkte hinter einem mobilen Router bzw. Kommunikations-Server (MR) angeordnet sein, wie es in 2 gezeigt ist, und wenn der Router bzw. Kommunikations-Server für das Verwalten der Verbindungsfähigkeit bzw. Konnektivität zu dem Internet verantwortlich ist, muss er Bindungs-Aktualisierungen im Namen der Knotenpunkte versenden. Der Knotenpunkt kann sich ebenso von hinter dem mobilen Router bzw. Kommunikations-Server wegbewegen, wobei es der Router bzw. Kommunikations-Server nicht länger wünschen sollte, diesen Dienst bereitzustellen. Eine Prozedur, um es dem mobilen Router bzw. Kommunikations-Server zu gestatten,. temporär Bindungs-Nachrichten im Namen eines Knotenpunktes zu versenden, lautet wie folgt:
    • 1. Der Knotenpunkt und der Router bzw. Kommunikations-Server einigen sich darauf, dass eine bestimmte Adresse bzw. Adressen für eine bestimmte Zeitdauer hinter dem Router bzw. Kommunikations-Server liegt bzw. liegen, und für die Mobilitätsverwaltung, die durch den Router bzw. Kommunikations-Server durchgeführt werden muss. Die Adresse gehört zu dem Schlüsselpaar (P, S), das im Besitz von dem Knotenpunkt steht.
    • 2. Der Knotenpunkt und der Router bzw. Kommunikations-Server können während dieses Prozesses optional zueinander authentisiert sein.
    • 3. Der Router bzw. Kommunikations-Server gibt während dieses Prozesses seinen im Besitz habenden öffentlichen Schlüssel Pr zu dem Knotenpunkt. Dieser öffentliche Schlüssel wird typischerweise permanent dem Router bzw. Kommunikations-Server zugeordnet. Der Router bzw. Kommunikations-Server kennt ebenso den Sicherheitsschlüssel Sr.
    • 4. Der Knotenpunkt bringt ein Zertifikat für Pr hervor, um die Adresse, die in Beziehung mit P steht, wahrzunehmen. Das heißt, der Knotenpunkt signiert das Tuple [Pr, Endzeit] mit S. Das Zertifikat weist folgendes auf: P und die Signatur.
    • 5. Wenn der Router bzw. Kommunikations-Server es wünscht, eine Bindungs-Aktualisierung über das Internet an einen entsprechenden Knotenpunkt zu versenden, signiert er die Anforderung mit Sr und hängt das Zertifikat, welches im Schritt 4 hervorgebracht wurde, an die Nachricht an.
    • 6. Der entsprechende Knotenpunkt, der die Bindungs-Aktualisierung empfängt, verifiziert zunächst, dass der Wert des Schnittstellen-Identifizierer-Teils der IP-Adresse des Knotenpunktes (der in der Bindungs-Aktualisierungs-Nachricht enthalten ist) in Beziehung zu dem öffentlichen Schlüssel P steht, und zwar, indem die Ein-Wege-Funktion h, die dem entsprechenden Knotenpunkt bekannt ist, an den öffentlichen Schlüssel P angewandt wird. Der Empfänger-Knotenpunkt verwendet den öffentlichen Schlüssel P, um zu verifizieren, dass das Zertifikat mit dem entsprechenden Sicherheitsschlüssel S richtig signiert ist, und stellt den öffentlichen Schlüssel Pr des Absender-Routers bzw. Kommunikations-Servers und die gültige Endzeit wieder her. Er verifiziert dann, dass die Signatur in der Bindungs-Aktualisierung mit dem privaten Schlüssel Sr, der dem in dem Zertifikat enthaltenen öffentlichen Schlüssel Pr entspricht, erzeugt wurde, wodurch bewiesen wird, dass der Absender-Router bzw. Kommunikations-Server in Besitz des öffentlichen Schlüssel Pr steht. Unter der Annahme, dass die Endzeit nicht abgelaufen ist, aktualisiert der Empfänger-Knotenpunkt seinen Bindungs-Cache mit der neuen Care-of-Adresse.
  • Die Prozedur kann mit dem nachfolgenden Signalisierungsablauf dargestellt werden, der ebenso in 5 gezeigt ist:
    • 1. Router bzw. Kommunikations-Server – Knotenpunkt: Biete Dienst an; Zeitdauer = T, öffentlicher Schlüssel des Routers bzw. Kommunikations-Servers = Pr
    • 2. Knotenpunkt – Router bzw. Kommunikations-Server: Start; Adresse = A, Zertifikat = P, {[Pr, Endzeit] signiert mit S}
    • 3. Router bzw. Kommunikations-Server – Anderer Knotenpunkt: Bindungs-Aktualisierung; Care-of-Adresse, Adresse = A, Signatur an der gesamten Nachricht mit Srl.
  • Für einen Fachmann ist es ersichtlich, dass verschiedene Abänderungen an den obig beschriebenen Ausführungsformen durchgeführt werden können, ohne von dem Umfang bzw. Kerngedanken der vorliegenden Erfindung abzuweichen.
  • Zusammenfassung
  • Ein Verfahren zum Übertragen von Verantwortung für eine im Besitz eines ersten IP-Netzknotenpunktes stehende IP-Adresse zu einem zweiten IP-Netzknotenpunkt, bei dem zumindest ein Teil der IP-Adresse von einem öffentlichen Schlüssel und einem öffentlichen/privaten Schlüsselpaar ableitbar ist, welches Schlüsselpaar zu dem ersten Knotenpunkt gehört. Das Verfahren weist die folgenden Verfahrensschritte auf: Benachrichtigen des ersten Knotenpunktes hinsichtlich eines öffentlichen Schlüssels eines öffentlich/privaten Schlüsselpaares, das zu dem zweiten Knotenpunkt gehört; Signieren des öffentlichen Schlüssels des zweiten Knotenpunktes mit dem privaten Schlüssel des ersten Knotenpunktes beim ersten Knotenpunkt, um ein Autorisierungszertifikat bereitzustellen; und Versenden des Autorisierungszertifikats von dem ersten Knotenpunkt zu dem zweiten Knotenpunkt, wobei das Autorisierungszertifikat anschließend in Nachrichten, die zu der IP-Adresse gehören, eingefügt und mit dem privaten Schlüssel des zweiten Knotenpunktes signiert wird, von dem zweiten Knotenpunkt zu Empfänger-Knotenpunkten versendet wird, und von den Empfänger-Knotenpunkten verwendet wird, um den Anspruch des zweiten Knotenpunktes auf die IP-Adresse zu verifizieren.

Claims (12)

  1. Verfahren zum Übertragen von Verantwortung für eine im Besitz eines ersten IP-Netzknotenpunktes stehende IP-Adresse zu einem zweiten IP-Netzknotenpunkt, bei dem zumindest ein Teil der IP-Adresse von einem öffentlichen Schlüssel und einem öffentlichen/privaten Schlüsselpaar ableitbar ist, welches Schlüsselpaar zu dem ersten Knotenpunkt gehört, wobei das Verfahren folgendes aufweist: Benachrichtigen des ersten Knotenpunktes hinsichtlich eines öffentlichen Schlüssels eines öffentlich/privaten Schlüsselpaares, das zu dem zweiten Knotenpunkt gehört; Signieren des öffentlichen Schlüssels des zweiten Knotenpunktes mit dem privaten Schlüssel des ersten Knotenpunktes beim ersten Knotenpunkt, um ein Autorisierungszertifikat bereitzustellen; und Versenden des Autorisierungszertifikats von dem ersten Knotenpunkt zu dem zweiten Knotenpunkt, wobei das Autorisierungszertifikat anschließend in Nachrichten, die zu der IP-Adresse gehören, eingefügt und mit dem privaten Schlüssel des zweiten Knotenpunktes signiert wird, von dem zweiten Knotenpunkt zu Empfänger-Knotenpunkten versendet wird, und von den Empfänger-Knotenpunkten verwendet wird, um den Anspruch des zweiten Knotenpunktes auf die IP-Adresse zu verifizieren.
  2. Verfahren nach Anspruch 1, bei dem der erste IP-Netzknotenpunkt ein DHCP-Server und der zweite IP-Netzknotenpunkt ein Client-Knotenpunkt ist.
  3. Verfahren nach Anspruch 1, bei dem der erste IP-Netzknotenpunkt ein Client-Knotenpunkt und der zweite IP-Netzknotenpunkt ein mobiler Router bzw. Kommunikations-Server ist.
  4. Verfahren nach einem der vorhergehenden Ansprüche, bei dem ein Schnittstellen-Identifizierer-Teil der IP-Adresse von dem öffentlichen Schlüssel des öffentlichen/privaten Schlüsselpaares, welches zu dem ersten Knotenpunkt gehört, ableitbar ist.
  5. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Nachrichten Bindungs-Aktualisierungs-Nachrichten gemäß dem Mobile-IP-Protokoll sind und das Autorisierungs-Zertifikat, die IP-Adresse und eine neue Care-of-Adresse enthalten.
  6. Verfahren nach einem der vorhergehenden Ansprüche, bei dem das Zertifikat abgeleitet wird, indem eine Kombination des öffentlichen Schlüssels des zweiten Knotenpunktes mit einem Zeit-Kennzeichen mit dem privaten Schlüssel des ersten Knotenpunktes signiert wird, wobei das Zeit-Kennzeichen jene Zeit ist, bei welcher die Autorisierung zur Verwendung der IP-Adresse ausläuft.
  7. Verfahren zum Authentifizieren einer Nachricht, welche bei einem Empfänger-Knotenpunkt eines IP-Netzes von einem Absender-Knotenpunkt empfangen wird, wobei die Nachricht zu einer IP-Adresse gehört und folgendes aufweist: die IP-Adresse, einen öffentlichen Schlüssel von einem öffentlichen/privaten Schlüsselpaar, das zu dem Knotenpunkt gehört, welcher in Besitz der IP-Adresse ist, und ein Zertifikat, welches von dem Besitzer-Knotenpunkt an den Absender-Knotenpunkt ausgegeben wird, und welches abgeleitet wird, indem der öffentliche Schlüssel eines öffentlichen/privaten Schlüsselpaares, das zu dem Absender-Knotenpunkt gehört, mit dem privaten Schlüssel des Besitzer-Knotenpunktes signiert wird, wobei die Nachricht mit dem privaten Schlüssel des Absender-Knotenpunktes signiert wird, wobei das Verfahren folgendes aufweist: Bestätigen, dass zumindest Teil der IP-Adresse von dem öffentlichen Schlüssel des Besitzer-Knotenpunktes ableitbar ist; Bestätigen, dass das Zertifikat mit dem privaten Schlüssel des Besitzer-Knotenpunktes signiert ist; und Bestätigen, dass die Nachricht mit dem privaten Schlüssel des Absender-Knotenpunktes signiert ist.
  8. Verfahren nach Anspruch 7, bei dem das Zertifikat abgeleitet wird, indem sowohl der öffentliche Schlüssel des öffentlichen/privaten Schlüsselpaares, das zu dem Absender-Knotenpunkt gehört, als auch ein Zeit- Kennzeichen signiert werden, und bei dem der Empfänger-Knotenpunkt bestätigt, dass das Zeit-Kennzeichen nicht vor dem Wirken an der Nachricht abgelaufen ist.
  9. IP-Client-Terminal, welches ausgelegt ist, eine IP-Adresse im Betrieb von einem anderen IP-Netzknotenpunkt zu mieten, wobei zumindest ein Teil der IP-Adresse von einem öffentlichen Schlüssel eines öffentlichen/privaten Schlüsselpaares, das zu dem Besitzer-Knotenpunkt gehört, ableitbar ist, wobei das Client-Terminal folgendes aufweist: eine Einrichtung zum Benachrichtigen des Besitzer-Knotenpunktes hinsichtlich eines öffentlichen Schlüssels eines öffentlichen/privaten Schlüsselpaares, welches zu dem Client-Terminal gehört; eine Einrichtung zum Empfangen eines Autorisierungszertifikates von dem Besitzer-Knotenpunkt, welches den öffentlichen Schlüssel des Client-Terminals enthält, der mit dem privaten Schlüssel des Besitzer-Knotenpunktes signiert ist; wobei das Autorisierungszertifikat anschließend in Nachrichten, die zu der IP-Adresse gehören, eingefügt und mit dem privaten Schlüssel des Client-Terminals signiert wird, von dem Client-Terminal zu Empfänger-Knotenpunkten versendet wird, und von den Empfänger-Knotenpunkten verwendet wird, um den Anspruch des Client-Terminals auf die IP-Adresse zu verifizieren.
  10. IP-Client-Terminal, welches ausgelegt ist, im Betrieb einen bevollmächtigten IP-Netzknotenpunkt dahingehend zu autorisieren, eine im Besitz von dem Client-Terminal stehende IP-Adresse zu verwenden, wobei zumindest ein Teil der IP-Adresse von einem öffentlichen Schlüssel eines öffentlichen/privaten Schlüsselpaares ableitbar ist, welches zu dem Client-Terminal gehört, wobei das Client-Terminal folgendes aufweist: eine Einrichtung zum Empfangen von dem bevollmächtigten Knotenpunkt eines öffentlichen Schlüssels eines öffentlichen/privaten Schlüsselpaares, welches zu dem bevollmächtigten Knotenpunkt gehört; eine Einrichtung zum Erzeugen eines Autorisationszertifikats, das den mit dem privaten Schlüssel des Client-Terminals signierten öffentlichen Schlüssel des bevollmächtigten Knotenpunktes enthält, und zum Versenden des Zertifikates zu dem bevollmächtigten Knotenpunkt; wobei das Autorisationszertifikat anschließend in Nachrichten, die zu der IP-Adresse gehören, eingefügt und mit dem privaten Schlüssel des bevollmächtigten Knotenpunktes signiert wird, von dem bevollmächtigten Knotenpunkt zu Empfänger-Knotenpunkten versendet wird, und von den Empfänger-Knotenpunkten verwendet wird, um den Anspruch des bevollmächtigten Knotenpunktes auf die IP-Adresse zu verifizieren.
  11. IP-Server, der ausgelegt ist, im Betrieb einen Client-IP-Knotenpunkt dahingehend zu autorisieren, eine im Besitz des Servers stehende IP-Adresse zu verwenden, wobei zumindest ein Teil der IP-Adresse von einem öffentlichen Schlüssel eines öffentlichen/privaten Schlüsselpaares ableitbar ist, das zu dem Server gehört, wobei der Server folgendes aufweist: eine Einrichtung zum Empfangen von dem Client-Terminal eines öffentlichen Schlüssels eines öffentlichen/privaten Schlüsselpaares, das zu dem Client-Terminal gehört; eine Einrichtung zum Erzeugen eines Autorisationszertifikats, das den mit dem privaten Schlüssel des Servers signierten öffentlichen Schlüssel des Client-Terminals enthält, und zum Versenden des Zertifikats zu dem Client-Terminal; wobei das Autorisationszertifikat anschließend in Nachrichten, die zu der IP-Adresse gehören, eingefügt und mit dem privaten Schlüssel des Client-Terminals signiert wird, von dem Client-Terminal zu Empfänger-Knotenpunkten versendet wird, und von den Empfänger-Knotenpunkten verwendet wird, um den Anspruch des Client-Terminals auf die IP-Adresse zu verifizieren.
  12. IP-Server, der ausgelegt ist, im Betrieb Verantwortung für eine IP-Adresse zu übernehmen, die im Besitz von einem Client-Terminal steht, wobei zumindest ein Teil der IP-Adresse von einem öffentlichen Schlüssel eines öffentlichen/privaten Schlüsselpaares ableitbar ist, das zu dem Client-Terminal gehört, wobei der Server folgendes aufweist: eine Einrichtung zum Versenden zu dem Client-Terminal eines öffentlichen Schlüssels von einem öffentlichen/privaten Schlüsselpaar, das zu dem Server gehört; eine Einrichtung zum Empfangen von dem Client-Terminal eines Autorisationszertifikats, das den mit dem privaten Schlüssel des Client-Terminals signierten öffentlichen Schlüssel des Servers enthält; wobei das Autorisationszertifikat anschließend in Nachrichten, die zu der IP-Adresse gehören, eingefügt und mit dem privaten Schlüssel des Servers signiert wird, von dem Server zu Empfänger-Knotenpunkten versendet wird, und von dem Empfänger-Knotenpunkten verwendet wird, um den Anspruch des Servers auf die IP-Adresse zu verifizieren.
DE10297253T 2001-10-26 2002-10-18 Adressiermechanismus in Mobile-IP Withdrawn DE10297253T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB0125715A GB2381423B (en) 2001-10-26 2001-10-26 Addressing mechanisms in mobile IP
GB0125715.3 2001-10-26
PCT/SE2002/001904 WO2003036916A2 (en) 2001-10-26 2002-10-18 Addressing mechanisms in mobile ip

Publications (1)

Publication Number Publication Date
DE10297253T5 true DE10297253T5 (de) 2005-02-17

Family

ID=9924573

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10297253T Withdrawn DE10297253T5 (de) 2001-10-26 2002-10-18 Adressiermechanismus in Mobile-IP

Country Status (6)

Country Link
US (1) US7401216B2 (de)
CN (1) CN100592746C (de)
DE (1) DE10297253T5 (de)
ES (1) ES2277495B1 (de)
GB (1) GB2381423B (de)
WO (1) WO2003036916A2 (de)

Families Citing this family (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7561553B2 (en) * 2002-02-27 2009-07-14 Motorola, Inc. Method and apparatus for providing IP mobility for mobile networks and detachable mobile network nodes
GB2405566B (en) * 2002-10-14 2005-05-18 Toshiba Res Europ Ltd Methods and systems for flexible delegation
JP2004242019A (ja) * 2003-02-05 2004-08-26 Ntt Docomo Inc 移動通信制御システム、ネットワーク管理サーバ、モバイルノード、アクセスノード及びアンカーノード
KR100513863B1 (ko) * 2003-04-29 2005-09-09 삼성전자주식회사 호스트의 이동성을 지원할 수 있는 무선 근거리 네트워크시스템 및 그의 동작방법
US7861288B2 (en) * 2003-07-11 2010-12-28 Nippon Telegraph And Telephone Corporation User authentication system for providing online services based on the transmission address
US7873036B2 (en) * 2004-02-03 2011-01-18 Nokia Siemens Networks Oy Method and apparatus to provide group management of multiple link identifiers for collective mobility
US7549048B2 (en) * 2004-03-19 2009-06-16 Microsoft Corporation Efficient and secure authentication of computing systems
US7991854B2 (en) * 2004-03-19 2011-08-02 Microsoft Corporation Dynamic session maintenance for mobile computing devices
EP1735990B1 (de) 2004-04-14 2018-05-30 Microsoft Technology Licensing, LLC Authentifizierung und authorisierung für mobile ipv6
ES2368566T3 (es) * 2004-08-20 2011-11-18 Telefonaktiebolaget Lm Ericsson (Publ) Conexión rápida a red.
KR100636318B1 (ko) * 2004-09-07 2006-10-18 삼성전자주식회사 ＣｏＡ 바인딩 프로토콜을 이용한 어드레스 오너쉽인증방법 및 그 시스템
GB2423448B (en) * 2005-02-18 2007-01-10 Ericsson Telefon Ab L M Host identity protocol method and apparatus
US7881468B2 (en) * 2005-04-08 2011-02-01 Telefonaktiebolaget L M Ericsson (Publ) Secret authentication key setup in mobile IPv6
US7907948B2 (en) * 2005-04-22 2011-03-15 Telefonaktiebolaget L M Ericsson (Publ) Providing anonymity to a mobile node in a session with a correspondent node
US7925027B2 (en) * 2005-05-02 2011-04-12 Ntt Docomo, Inc. Secure address proxying using multi-key cryptographically generated addresses
US8098823B2 (en) * 2005-05-03 2012-01-17 Ntt Docomo, Inc. Multi-key cryptographically generated address
EP1902566B3 (de) * 2005-07-08 2011-12-21 Panasonic Corporation Mobiler knoten und kommunikationssteuerungsverfahren
JP2007189620A (ja) * 2006-01-16 2007-07-26 Kddi Corp Ｉｐアドレス管理サーバ、利用者端末、およびプログラム
JP4890867B2 (ja) * 2006-01-17 2012-03-07 キヤノン株式会社 情報処理装置およびその制御方法
GB0601913D0 (en) * 2006-01-31 2006-03-08 Ericsson Telefon Ab L M Packet re-direction in a communication network
US7814311B2 (en) * 2006-03-10 2010-10-12 Cisco Technology, Inc. Role aware network security enforcement
US9179318B2 (en) 2006-05-24 2015-11-03 Telefonaktiebolaget Lm Ericsson (Publ) Delegation based mobility management
DE602006010251D1 (de) 2006-05-24 2009-12-17 Ericsson L M Oy Mobilitätsverwaltung auf delegationsbasis
US7958368B2 (en) * 2006-07-14 2011-06-07 Microsoft Corporation Password-authenticated groups
US8041942B2 (en) * 2006-09-05 2011-10-18 Panasonic Corporation Robust peer-to-peer networks and methods of use thereof
EP1906615A1 (de) * 2006-09-29 2008-04-02 Nokia Siemens Networks Gmbh & Co. Kg Verfahren und Vorrichtungen zur Delegation der Steuerung von gesichterten Verbindungen
US8307411B2 (en) * 2007-02-09 2012-11-06 Microsoft Corporation Generic framework for EAP
CN101242269B (zh) * 2007-02-09 2011-12-07 西门子（中国）有限公司 预订电信服务的移动通信终端、服务提供商终端、系统及方法
ATE537648T1 (de) * 2007-02-12 2011-12-15 Ericsson Telefon Ab L M Signalisierungsdelegation in einem beweglichen netzwerk
CN101022418B (zh) * 2007-03-14 2010-05-26 华为技术有限公司 Hmip认证方法、设备及系统
US8266427B2 (en) * 2007-06-08 2012-09-11 Cisco Technology, Inc. Secure mobile IPv6 registration
CN101335744B (zh) * 2007-06-29 2013-06-05 华为技术有限公司 一种加密生成地址的配置方法、系统和装置
US9177313B1 (en) * 2007-10-18 2015-11-03 Jpmorgan Chase Bank, N.A. System and method for issuing, circulating and trading financial instruments with smart features
GB2454897A (en) * 2007-11-22 2009-05-27 Ericsson Telefon Ab L M Cryptographically generated IP addresses
WO2009068115A1 (en) * 2007-11-30 2009-06-04 Telefonaktiebolaget Lm Ericsson (Publ) Methods for secure sip signalling to a destination ip address being a cryptographi cally generated address (cga)
US8893242B2 (en) * 2008-04-29 2014-11-18 Ebay Inc. System and method for pool-based identity generation and use for service access
CN101616006A (zh) * 2009-07-31 2009-12-30 中兴通讯股份有限公司 证书管理方法、装置及系统
CN101631024A (zh) * 2009-08-11 2010-01-20 中兴通讯股份有限公司 一种增强的证书管理方法和系统
US8498414B2 (en) * 2010-10-29 2013-07-30 Telefonaktiebolaget L M Ericsson (Publ) Secure route optimization in mobile internet protocol using trusted domain name servers
CN102368740A (zh) * 2011-12-01 2012-03-07 北京交通大学 一种网络寻址方法
US10333696B2 (en) 2015-01-12 2019-06-25 X-Prime, Inc. Systems and methods for implementing an efficient, scalable homomorphic transformation of encrypted data with minimal data expansion and improved processing efficiency
JP7437722B2 (ja) * 2019-01-31 2024-02-26 コネクトフリー株式会社 データ送信方法、通信処理方法、装置、および通信処理プログラム
US10721198B1 (en) * 2019-04-15 2020-07-21 Microsoft Technology Licensing, Llc Reducing avoidable transmission of an attachment to a message by comparing the fingerprint of a received attachment to that of a previously received attachment and indicating to the transmitting user when a match occurs that the attachment does not need to be transmitted
US10721193B1 (en) * 2019-04-15 2020-07-21 Microsoft Technology Licensing, Llc Reducing avoidable transmission of an attachment to a message by comparing the fingerprint of the attachment to be sent to that of an attachment that was previously sent or received by the user and indicating to the user when a match occurs that the attachment is redundant

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4759063A (en) * 1983-08-22 1988-07-19 Chaum David L Blind signature systems
US6035402A (en) * 1996-12-20 2000-03-07 Gte Cybertrust Solutions Incorporated Virtual certificate authority
US6513116B1 (en) * 1997-05-16 2003-01-28 Liberate Technologies Security information acquisition
US6292897B1 (en) * 1997-11-03 2001-09-18 International Business Machines Corporation Undeniable certificates for digital signature verification
US7032242B1 (en) * 1998-03-05 2006-04-18 3Com Corporation Method and system for distributed network address translation with network security features
WO2001031472A1 (en) * 1999-10-22 2001-05-03 Telcordia Technologies, Inc. Method and system for host mobility management protocol
US6826690B1 (en) * 1999-11-08 2004-11-30 International Business Machines Corporation Using device certificates for automated authentication of communicating devices
FR2802666B1 (fr) * 1999-12-17 2002-04-05 Activcard Systeme informatique pour application a acces par accreditation
US6978364B1 (en) * 2000-04-12 2005-12-20 Microsoft Corporation VPN enrollment protocol gateway
US6925075B2 (en) * 2000-07-31 2005-08-02 Telefonaktiebolaget Lm Ericsson Method and system for inter-operability between mobile IP and RSVP during route optimization
KR100520141B1 (ko) * 2000-10-26 2005-10-10 삼성전자주식회사 이동통신 시스템에서 고정 주소를 가지는 이동단말의 핸드오버 방법
US20020106085A1 (en) * 2001-01-05 2002-08-08 Sandeep Jain Security breach management
GB2367986B (en) * 2001-03-16 2002-10-09 Ericsson Telefon Ab L M Address mechanisms in internet protocol
US7203966B2 (en) * 2001-06-27 2007-04-10 Microsoft Corporation Enforcement architecture and method for digital rights management system for roaming a license to a plurality of user devices
US20030018964A1 (en) * 2001-07-19 2003-01-23 International Business Machines Corporation Object model and framework for installation of software packages using a distributed directory

Also Published As

Publication number Publication date
GB0125715D0 (en) 2001-12-19
US20030084293A1 (en) 2003-05-01
WO2003036916A3 (en) 2003-11-13
GB2381423A (en) 2003-04-30
GB2381423B (en) 2004-09-15
WO2003036916A2 (en) 2003-05-01
ES2277495A1 (es) 2007-07-01
US7401216B2 (en) 2008-07-15
ES2277495B1 (es) 2008-07-01
CN100592746C (zh) 2010-02-24
CN1636378A (zh) 2005-07-06

Similar Documents

Publication Publication Date Title
DE10297253T5 (de) Adressiermechanismus in Mobile-IP
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
DE69831974T2 (de) Verfahren zur paketauthentifizierung in gegenwart von netzwerkadressübersetzungen und protokollumwandlungen
EP2052517B1 (de) Verfahren und system zum bereitstellen eines zugangsspezifischen schlüssels
DE60302882T2 (de) Sicherheitsübertragungsprotokoll für ein mobilitäts-ip-netzwerk
DE102006031870B4 (de) Verfahren und System zum Bereitstellen eines Mobile IP Schlüssels
DE10296445B4 (de) Adress-Mechanismen im Internet-Protokoll
DE69923942T2 (de) Verfahren und System zur drahtlosen mobile Server und Gleichrangigendiensten mit Dynamische DNS Aktualisierung
DE102006004868B4 (de) Verfahren und Server zum Bereitstellen eines Mobilitätsschlüssels
DE60305869T2 (de) Kommunikation zwischen einem privatem Netzwerk und einem mobilem Endgerät
DE102006008745A1 (de) Verfahren und Server zum Bereitstellen eines Mobilitätsschlüssels
DE60201522T2 (de) Ermöglichen legales abfangen von ip-verbindungen
EP1943806B1 (de) Teilnehmerspezifisches erzwingen von proxy-mobile-ip (pmip) anstelle von client-mobile-ip (cmip)
EP1943856B1 (de) Verfahren und server zum bereitstellen eines mobilitätsschlüssels
DE102006006072B3 (de) Verfahren zum Sichern der Authentizität von Nachrichten, die gemäß einem Mobile Internet Protokoll ausgetauscht werden
DE602004001606T2 (de) Return-Routability-Verfahren zur sicheren Kommunikation
WO2007068613A1 (de) Verfahren zur übertragung von auf dem ethernet-übertragungsprotokoll basierenden datenpaketen zwischen zumindest einer mobilen kommunikationseinheit und einem kommunikationssystems
EP2062400B1 (de) Verfahren und system zur adressierung und zum routing bei verschlüsselten kommunikationsbeziehungen
EP1776821B1 (de) System und verfahren zum sicheren anmelden in einem kommuniktionssystem mit netzwerkverbindungs- und verbindungssteuerungs-rechnern
DE102004047692A1 (de) Kommunikationssystem und Verfahren zur Bereitstellung eines mobilen Kommunikationsdienstes
DE602004000762T2 (de) Verfahren und System zur Steuerung des Weiterreichens eines Endgeräts
DE102013017789A1 (de) System für eine abgesicherte LAN-über-WAN-Übertragung
WO2007093245A1 (de) Verfahren zur übermittlung von daten in einem kommunikationsnetz

Legal Events

Date Code Title Description
8110 Request for examination paragraph 44
8125 Change of the main classification

Ipc: H04W 12/06 AFI20051017BHDE

R016 Response to examination communication
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee