DE10296445B4 - Adress-Mechanismen im Internet-Protokoll - Google Patents

Adress-Mechanismen im Internet-Protokoll Download PDF

Info

Publication number
DE10296445B4
DE10296445B4 DE10296445T DE10296445T DE10296445B4 DE 10296445 B4 DE10296445 B4 DE 10296445B4 DE 10296445 T DE10296445 T DE 10296445T DE 10296445 T DE10296445 T DE 10296445T DE 10296445 B4 DE10296445 B4 DE 10296445B4
Authority
DE
Germany
Prior art keywords
host
address
interface identifier
public key
components
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.)
Expired - Lifetime
Application number
DE10296445T
Other languages
English (en)
Other versions
DE10296445T5 (de
Inventor
Pekka Nikander
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 DE10296445T5 publication Critical patent/DE10296445T5/de
Application granted granted Critical
Publication of DE10296445B4 publication Critical patent/DE10296445B4/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/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
    • 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
    • H04L61/50—Address allocation
    • H04L61/5092—Address allocation by self-assignment, e.g. picking addresses at random and testing if they are already in use
    • 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1458—Denial of Service

Abstract

Verfahren zum Verifizieren, dass ein an ein IP-Netz angeschlossener Host autorisiert ist, eine IP-Adresse zu verwenden, welche der Host als eigen beansprucht, wobei die IP-Adresse einen Routing- bzw. -Identifizierer-Teil aufweist, wobei das Verfahren folgende Verfahrensschritte aufweist: – Empfang von einer oder mehreren Komponenten von dem Host; – Anwenden einer Ein-Wege-Codier-Funktion an der oder an jeder Komponente und/oder Ableitungen von der oder von jeder Komponente; und – Vergleich des Ergebnisses oder einer Ableitung des Ergebnisses gegenüber dem Schnittstellen-Identifizierer-Teil der IP-Adresse, wobei, wenn das Ergebnis oder seine Ableitung mit dem Schnittstellen-Identifizierer übereinstimmt, der Host als autorisiert gilt, die IP-Adresse zu verwenden, und wenn das Ergebnis oder seine Ableitung nicht mit dem Schnittstellen-Identifizierer übereinstimmt, der Host als nicht autorisiert gilt, die IP-Adresse zu verwenden.

Description

  • Technisches Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft Adress-Mechanismen im Internet-Protokoll (IP) und im einzelnen Adress-Mechanismen in IPv6.
  • Hintergrund der Erfindung
  • Der gewaltige Wachstum bei der Verwendung des Internets hat Schwächen und Einschränkungen des gegenwärtigen, als IPv4 bekannten Internet-Protokolls an den Tag gelegt. Die Internet Engineering Task Force (IETF), die eine lose Verbindung von interessierten Parteien ist, entwickelt von daher ein verbessertes Internet-Protokoll, welches als IPv6 bekannt ist. Im einzelnen enthält IPv6 wesentlich verbesserte Sicherheitsmechanismen, die als IPSec bekannt sind, welche zwei oder mehrere Parteien in die Lage versetzen, auf sicherem Wege über das Internet zu kommunizieren, sowie Vorkehrungen für einen mobilen Internetzugriff (mobileIP) bereitstellen. MobileIP gestattet es einem Benutzer, auf das Internet zuzugreifen, während er sich bewegt, indem er von einem IP-Zugriffsknotenpunkt zu einem anderen roamt. MobileIP wird im einzelnen von solchen Benutzern verwendet, die auf das Internet über kabellose Mobilvorrichtungen (die beispielsweise mit Wireless LANs und zellularen Telefonnetzwerken verbunden sind) zugreifen.
  • IPv6 bietet für eine wesentlich größere IP-Adresse Raum, den IP-Adressen von 128 Bits in der Länge voraussetzen. Die ersten 64 Bits einer Adresse bilden einen Routing-Vorspann bzw. Leitwegelenkungs-Vorspann, welcher eindeutig den durch ein IP-Terminal oder Host verwendeten Internet-Zugriffsknotenpunkt (oder eine sogenannte „lokale Verknüpfung”) identifiziert, während die letzten 64 Bits einen Host-Nachspann ausbilden, welcher eindeutig das Mobilterminal zu dem Zugriffsknotenpunkt (oder innerhalb der lokalen Verknüpfung) identifiziert. Der Host-Nachspann wird als ein „Schnittstellen-Identifizierer” bezeichnet, da er den Host über die Zugriffsschnittstelle eindeutig identifiziert. Wenn sich ein Host bei einem Zugriffsknotenpunkt anmeldet, dann lernt der Host typischerweise den Routing-Vorspann des Zugriffsknotenpunktes von einer Ankündigungsnachricht, die von dem Zugriffsknotenpunkt gesendet wird. Gemäß RFC3041 (IETF) erzeugt dann ein Host seinen Schnittstellen-Identifizierer unter Verwendung einer mittels des Hosts erzeugten Zufallszahl. Der Host kann zusätzlich eine Sicherungsschicht
    Figure 00020001
    bzw. Verbindungsschicht-Adresse verwenden, um den Schnittstellen-Identifizierer zu erzeugen, wobei die Sicherungsschicht- bzw. Verbindungsschicht-Adresse beispielsweise eine von dem Zugriffsnetz verwendete MAC-Schicht-Adresse ist.
  • Ein potentielles Problem mit diesem Ansatz liegt darin, dass zwei mit dem gleichen Zugriffsknotenpunkt verbundene Hosts (und von daher den gleichen Routing-Vorspann aufweisen), die gleichen Schnittstellen-Identifizierer und von daher die gleichen IP-Adressen erzeugen können. Dieses darf nicht vorkommen. Von daher sieht IPv6 einen als Duplicate Adress Detektion (DAD) bzw. Zweitadressen-Erfassung bekannten Mechanismus vor. Sobald ein Host eine potentielle IP-Adresse erzeugt hat, sendet er eine Nachbar-Ansuchungs-Nachricht, welche die vorgeschlagene IP-Adresse enthält, an den Zugriffsknotenpunkt oder direkt an die lokale Verknüpfung, wenn die lokale Verknüpfung für lokale Übertragung oder Multicast vorgesehen ist. Falls erforderlich, überträgt der Zugriffsknotenpunkt die Nachricht an sämtliche Hosts, die mit dem Knotenpunkt verbunden sind. Wenn ein Host, der die Nachricht empfängt, bemerkt, dass die in der Nachricht enthaltene IP-Adresse eine Adresse ist, die er bereits angenommen hat, dann antwortet dieser Host, indem er an dem ansuchenden Host eine Nachbar-Ankündigungs-Nachricht sendet. Wenn ein ansuchender Host innerhalb einer bestimmten Zeit keine Nachbar-Ankündigungs-Nachricht empfängt, dann wird er die erzeugte Adresse annehmen. Wenn andererseits innerhalb der bestimmten Zeit eine Nachbar-Ankündigungs-Nachricht empfangen wird, dann wird der ansuchende Host einen neuen Schnittstellen-Identifizierer und eine neue IP-Adresse erzeugen und den Ansuchungsprozess wiederholen.
  • Ein Problem bei dem oben beschriebenen Ansatz liegt darin, dass es für eine böswillige dritte Partei relativ einfach sein kann, den ansuchenden Knotenpunktzugriff zu verweigern, indem grundsätzlich auf eine Nachbar-Ansuchungs-Nachricht mit einer Nachbar-Ankündigungs-Nachricht geantwortet wird. Diese Art von Attacke ist als „Dienstverweigerungs-Attacke” bekannt.
  • Ein weiteres Problem kann in IPv6 mit MobileIP entstehen. Wie bereits erwähnt, gestattet es MobileIP, dass Hosts zwischen Zugriffsknotenpunkten und sogar zwischen Zugriffsnetzwerken umherwandern, eine Eigenschaft, die es erforderlich macht, dass es den Hosts gestattet ist, die IP-Adressen zu ändern, welche ihren gegenwärtigen physikalischen Standort definieren. Typischerweise wird einem mobilen Host eine „feste” Heimat-IP-Adresse in einem Heimat-Netzwerk zugewiesen. Wenn der Host zu Hause ist, dann kann er diese Heimatadresse als seine physikalische Adresse verwenden. Wenn sich jedoch ein Host selbst an einen „fremden” Zugriffsknotenpunkt anhängt, dann wird dem Host eine temporäre Care-of-Adresse zugewiesen. Hosts, die mit dem mobilen Host übereinstimmen, erhalten einen Binding-Cache, der Zuordnungen zwischen Heimatadressen und Care-of-Adressen enthält. Für eintreffende Pakete ändert die MobileIP-Schicht bei einem entsprechenden Host die Care-of-Adresse für die Heimatadresse in das Bestimmungsfeld, während für abgehende Pakete die MobileIP-Schicht bei einem entsprechenden Host die Heimatadresse für die Care-of-Adresse in das Zieladressen-Feld ändert. Wenn ein mobiler Host eine Care-of-Adresse erhält, dann muss er eine Einding-Aktualisierungs-Nachricht an alle entsprechenden Hosts senden, um ihre Binding-Caches zu aktualisieren.
  • Ein potentielles Risiko von diesem Mechanismus liegt darin, dass eine böswillige dritte Partei in der Lage sein kann, eine fehlerhafte Binding- bzw. Anbindungs-Aktualisierung an einen entsprechenden Host zu senden, um zu veranlassen, dass Datenpakete, die für einen mobilen Host beabsichtigt sind, an die böswillige Partei geroutet bzw. leitweggelenkt werden. Wenn die Pakete dann durch die böswillige Partei an den mobilen Host weitergeleitet werden (nachdem sie von dieser Partei geöffnet und gelesen wurden), kann der mobile Host nicht wissen, dass seine Pakete zurückgeroutet und gelesen wurden. Dieses Problem ist nicht auf MobileIP beschränkt, sondern tritt ebenso in anderen Signalisierungsfunktionen innerhalb der IPv6-Architektur auf. Die im Zusammenhang mit MobileIP bestehenden Probleme und einige der anderen Probleme werden detaillierter in dem IETF-Vortrag „draft-nikanderipng-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. Dieses schließt das Erzeugen eines zweckgebundenen Schlüssel(PBK)-Paares bei dem mobilen Host ein, das einen öffentlichen und einen privaten Schlüssel aufweist. Bei dem mobilen Host wird durch das Anwenden einer Hash-Funktion auf den öffentlichen Schlüssel eine Endpunkt-ID (EID) erzeugt. Die EID wird an einen entsprechenden Host gesendet, sobald eine IP-Verbindung initiiert ist. Dem nachfolgend sendet der mobile Host den öffentlichen Schlüssel an den entsprechenden Host
    Figure 00050001
    der entsprechende Host ist in der Lage, zu verifizieren, dass der öffentliche Schlüssel zu der Verbindung „gehört”, indem die Ein-Wege-Codier-Funktion bei dem Schlüssel angewandt wird und indem das Ergebnis mit der zuvor empfangenen EID verglichen wird. Jede Binding Aktualisierung, die nachfolgend gesendet wird, wird bei dem mobilen Host mit dem privaten Schlüssel des Hosts signiert. Der entsprechende Host verifiziert die Signatur, die an der Binding-Aktualisierung angefügt ist, indem er den zuvor empfangenen öffentlichen Schlüssel verwendet.
  • Zusammenfassung der vorliegenden Erfindung
  • Oben wurden zwei Probleme bei IPv6 betrachtet, nämlich die Möglichkeit einer Dienstverweigerungs-Attacke, die durch das Senden einer Nachbar-Ankündigungs-Nachricht an einen ansuchenden Host eingeführt wird, und einer „Mann-in-der-Mitte”-Attacke, die auf einer Falschausstellung von Binding-Aktualisierungen basiert. Ähnliche Probleme können in den folgenden Situationen auftreten: ICMP Router Discovery (RFC2461 Abschnitt 6.1.2), ICMP Redirect (RFC 2461 Abschnitt 8.1), Generic Tunnelling (RFC2473); Ipsec Tunnelling (RFC 2401), Router Renumbering (RFC2894), IPv6 Routing Header (RFC2460 Abschnitt 8.4), und möglicherweise in der Inverse Neighbour Discovery (draft-ietf-ion-ipvo-ind-05.txt) und SCTP (RFC2960). Es kann ebenso in dem HIP-Vorschlag sowie in einer Anzahl anderer Vorschläge auftreten. Sämtliche Probleme haben einen gemeinsamen Grund
    Figure 00060001
    es ist nicht möglich, den Besitzer einer IP-Adresse zu verifizieren.
  • In Anbetracht des Vorschlages von Bradner bindet der PBK den öffentlichen Schlüssel nicht an eine IP-Adresse, sondern vielmehr nur an die EID. Des weiteren gibt es keine direkte Bindung zwischen der EID und der IP-Adresse. Von daher verbessert der PBK nicht direkt die beschriebenen Probleme.
  • Eine Aufgabe der vorliegenden Erfindung liegt darin, die obig genannten Probleme zu lösen. Im einzelnen liegt eine Aufgabe der vorliegenden Erfindung darin, eine Einrichtung zum Überprüfen des Besitzers einer IP-Adresse bereitzustellen. In diesem Dokument bezeichnet der Besitz einer IP-Adresse, dass der Besitzer autorisiert ist, die IP-Adresse innerhalb des bestimmten Umfanges der Adresse zu verwenden, und dass er autorisiert ist, die Routing- bzw. Leitwegelenkungs-Information zu ändern, die für die IP-Adresse gilt.
  • Gemäß einem ersten Aspekt der vorliegenden Erfindung wird ein Verfahren angegeben, um zu verifizieren, dass ein an ein IP-Netz gekoppelter Host autorisiert ist, eine IP-Adresse zu verwenden, die der Host als Besitz beansprucht, wobei die IP-Adresse einen Routing- bzw. Leitwegelenkungs-Vorspann und einen Schnittstellen-Identifizierer-Teil aufweist, wobei das Verfahren folgende Schritte aufweist: Empfang von einer oder mehreren Komponenten von dem Host, Anwendung einer Ein-Wege-Codier-Funktion an der oder an sämtlichen Komponenten und/oder an Ableitungen von der oder von jeder Komponente, und Vergleich des Ergebnisses oder einer Ableitung des Ergebnisses gegenüber dem Schnittstellen-Identifizierer-Teil der IP-Adresse, wobei, wenn das Ergebnis oder seine Ableitung mit dem Schnittstellen-Identifizierer übereinstimmt, der Host als autorisiert angenommen wird, die IP-Adresse zu verwenden, und wobei, wenn das Ergebnis oder seine Ableitung nicht mit dem Schnittstellen-Identifizierer übereinstimmt, der Host als nicht autorisiert angesehen wird, die IP-Adresse zu verwenden.
  • Es wird einsehbar sein, dass ein Host den Schnittstellen-Identifizierer-Teil von seiner IP-Adresse unter Verwendung der Komponente bzw. der Komponenten und/oder der Ableitungen der Komponente bzw. der Komponenten erzeugen wird. Wenn eine Vielzahl von Komponenten involviert ist, dann kann die Ein-Wege-Codier-Funktion an einer Kombination von bestimmten dieser Komponenten und Ableitungen von anderen der Komponenten angewandt werden. Der erzeugende Host wird diese Komponenten während einer Verbindung aufbewahren, und er wird in der Lage sein, diese bei Bedarf einer anderen Partei zur Verfügung zu stellen. Die andere Partei kann die Komponenten verwenden, um den Schnittstellen-Identifizierer zu rekonstruieren und um den Besitz der IP-Adresse von dem Host zu verifizieren. Für eine böswillige dritte Partei ist es schwierig, die Codierung zu umzukehren und die Komponenten von der IP-Adresse zurückzugewinnen, und von daher den wahren Besitzer einer Adresse zu personifizieren bzw. sich als den Besitzer einer Adresse auszugeben.
  • Diese Ein-Wege-Codier-Funktion kann SHA-1, MD5, oder irgendeine andere bekannte, kryptographische Ein-Wege-Codier-Funktion sein.
  • Ein Vorteil von Ausführungsformen der vorliegenden Erfindung ist der, dass sie nicht irgendwelche globale Infrastrukturen, wie etwa eine Public Key Infrastruktur (PKI), erfordern, sondern auf einer neuen Anwendung kryptographischer Funktionen basieren. Da bestimmte Ausführungsformen dieser Erfindung keine Architekturänderungen bezüglich der gegenwärtig vorgeschlagenen IPv6-Spezifikationen erfordern, ist des weiteren die vorliegende Erfindung vorteilhafter als der obig betrachtete Bradner-Vorschlag, welcher Änderungen in der gegenwärtig verwendeten IPv6-Architektur erfordern würde.
  • Das IP-Netzwerk kann das Internet oder ein privates IP-Netz, wie etwa LAN oder WAN, aufweisen. Das IP-Netz kann ein Zugriffsnetz, das mit dem Internet und/oder einem privaten IP-Netz gekoppelt ist, aufweisen.
  • In bevorzugter Weise weisen die Komponenten einen mittels des Hosts erzeugten oder von einer anderen Partei an den Host ausgestellten öffentlichen Schlüssel, oder einen Auszug eines öffentlichen Schlüssels oder eine feste (beispielsweise Null) Sequenz der gleichen Länge, und einen Hash-Wert auf, der eine Wert einer Sequenz von ähnlichen Hash-Werten ist. Alternativ hierzu oder zusätzlich hierzu umfassen die Komponenten einen Anfangs-Schnittstellen-Identifizierer, der einer Sicherungs- bzw. Verbindungsschicht-Adresse des Hosts entspricht oder von einer Sicherungs- bzw. Verbindungsschicht-Adresse des Hosts abgeleitet ist, oder eine feste (beispielsweise Null) Bit-Sequenz der gleichen Länge. Noch bevorzugter umfassen die Komponenten sowohl den öffentlichen Schlüssel oder einen Auszug eines öffentlichen Schlüssels als auch den Anfangs-Schnittstellen-Identifizierer, der einer Sicherungs- bzw. Verbindungsschicht-Adresse des Hosts entspricht oder von einer Sicherungs- bzw. Verbindungsschicht-Adresse des Hosts abgeleitet ist, oder eine feste (beispielsweise Null) Bit-Sequenz der gleichen Länge. Noch bevorzugter umfassen die Komponenten einen Zählerwert, der die Position des empfangenen Hash-Wertes in der Sequenz identifiziert.
  • In bevorzugter Weise werden die Serie der Hash-Werte bei dem Host durch Anwenden einer Ein-Wege-Codier-Funktion an einem Keimwert, dem öffentlichen Schlüssel oder einem Auszug des öffentlichen Schlüssels und dem Anfangs-Schnittstellen-Identifizierer abgeleitet. Alternativ hierzu wird die Serie der Hash-Werte bei dem Host durch Anwenden einer Ein-Wege-Codier-Funktion an dem Keimwert und entweder an dem öffentlichen Schlüssel oder einem Auszug des öffentlichen Schlüssel oder an dem Anfangs-Schnittstellen-Identifizierer abgeleitet. Der Hash-Wert, der von dem empfangenen Hash-Wert ableitbar ist, und welcher verwendet wird, um das Ergebnis zu erzeugen, ist der letzte Hash-Wert in der Sequenz. In dem Fall einer ersten IP-Adressen-Verifikation ist der von dem Host empfangene Hash-Wert der Hash-Wert, der dem End-Hash-Wert in der Sequenz vorausgeht. Für jeden nachfolgenden Verifikationsprozess muss der nächste vorangehende Hash-Wert empfangen werden.
  • In bevorzugter Weise umfasst das Verfahren das Ableiten des Endwertes der HASH-Sequenz und das Anwenden einer Ein-Wege-Codier-Funktion an diesem Endwert, welcher mit einer oder mehreren anderen Komponenten verknüpft ist. Das Ergebnis kann vor dem Vergleich des Endergebnisses mit dem Schnittstellen-Identifizierer weiterverarbeitet werden.
  • Gemäß einem zweiten Aspekt der vorliegenden Erfindung wird ein Verfahren des Erzeugens einer IP-Adresse bei einem Host angegeben, wobei die IP-Adresse einen Routing- bzw. Leitwegelenkungs-Vorspann und einen Schnittstellen-Identifizierer-Teil aufweist, wobei das Verfahren das Erzeugen des Schnittstellen-Identifizierer-Teils durch Anwenden einer Ein-Wege-Codier-Funktion an einer Komponente oder mehreren Komponenten aufweist.
  • In bevorzugter Weise weisen die Komponenten einen Hash-Wert auf, der mittels eines Verfahrens erzeugt wird, das Information von einer Zufallszahl verwendet. In bevorzugter Weise wird der Hash-Wert durch Anwenden einer Ein-Wege-Codier-Funktion an einer Kombination der Zufallszahl und einem Anfangs-Schnittstellen-Identifizierer, einem öffentlichen Schlüssel oder einem Auszug des öffentlichen Schlüssels, oder an einer Kombination des Anfangs-Schnittstellen-Identifizierers und einem öffentlichen Schlüssel oder eines Auszuges des öffentlichen Schlüssels erzeugt.
  • Gemäß einem dritten Aspekt der vorliegenden Erfindung wird ein Verfahren des Unterlaufens bzw. des Vermeidens der Duplikation der IP-Adresse in einem IP-Netz angegeben, wenn sich ein neuer Host an das Netzwerk anbindet, wobei das Verfahren die folgenden Verfahrensschritte aufweist:
    Erzeugen eines Schnittstellen-Identifizierers bei dem neuen Host durch Kombination einer Komponente oder Komponenten und/oder Ableitungen der Komponente oder Komponenten unter Verwendung einer Ein-Wege-Codier-Funktion und unter Verwendung des Ergebnisses oder einer Ableitung des Ergebnisses als den Schnittstellen-Identifizierer, wobei der Schnittstellen-Identifizierer einen Teil der IP-Adresse ausbildet;
    Versenden einer Nachbar-Ansuchungs-Nachricht von dem neuen Host an andere Hosts, die bereits an das Zugriffsnetz angeschlossen sind;
    Empfang einer Nachbar-Ankündigungs-Nachricht bei dem neuen Host von jedem anderen Host, der die IP-Adresse für sich beansprucht, wobei die oder jede Nachbar-Ankündigungs-Nachricht die Komponente bzw. die Komponenten enthält; und
    für jede empfangene Nachbar-Ankündigungs-Nachricht:
    Kombination der Komponente bzw. der Komponenten und/oder der Ableitungen der Komponente bzw. der Komponenten unter Verwendung der Codier-Funktion; und
    Vergleich des Ergebnisses oder einer Ableitung des Ergebnisses gegenüber dem Schnittstellen-Identifizierer-Teil der IP-Adresse, wobei, wenn das Ergebnis oder die Ableitung des Ergebnisses mit dem Schnittstellen-Identifizierer übereinstimmt, der Host, von welchem die Nachbar-Ankündigungs-Nachricht empfangen wird, als autorisiert gilt, die IP-Adresse zu verwenden, und, wenn das Ergebnis oder seine Ableitung nicht mit dem Schnittstellen-Identifizierer übereinstimmt, dieser Host als nicht autorisiert gilt, die IP-Adresse zu verwenden.
  • In bevorzugter Weise weist bzw. weisen die Komponente bzw. die Komponenten einen öffentlichen Schlüssel, einen Auszug eines öffentlichen Schlüssels oder eine Ableitung hiervon auf. Dieses gestattet es dem neuen Host, einen öffentlichen Schlüssel derart zu lernen, dass der neue Host auf sichere Weise annehmen kann, dass der Host, der die Ankündigung sendet, den öffentlichen Schlüssel verwendet, um seine IP-Adresse zu erzeugen, und von daher kann der neue Host annehmen, dass der andere Host im Besitz des entsprechenden privaten Schlüssels sein muss, um bezüglich der IP-Adresse autorisiert zu sein.
  • Basierend auf der obig genannten Annahme kann in bevorzugter Weise der neue Host jedes wohlbekannte Authentitations-Protokoll oder andere auf einem öffentlichen Schlüssel kryptographisch basierende Protokolle (wie etwa Zero-Knowledge-Protokolle) verwenden, um zu verifizieren, dass der andere Host gegenwärtig im Besitz des notwendigen privaten Schlüssels ist. In bevorzugter Weise wird bei erfolgreichem Ablauf des (Verifikations-)Protokolls angenommen, dass der andere Host autorisiert ist, die IP-Adresse zu verwenden, und bei einem Fehlschlagen des erfolgreichen Ablaufes des Protokolls wird angenommen, dass der andere Host nicht autorisiert ist, die IP-Adresse zu verwenden.
  • Gemäß einem vierten Aspekt der vorliegenden Erfindung wird ein Verfahren angegeben zum Verifizieren, dass ein Host, der an ein IP-Netz gekoppelt ist, autorisiert ist, eine IP-Adresse zu verwenden, welche der Host als seine eigene beansprucht, und dass der Host in der Lage ist, Datenpakete, die zu dieser Adresse gesendet werden, zu empfangen, wobei das Verfahren folgende Verfahrensschritte aufweist:
    Ausführen des Verfahrens des obigen ersten Aspekts der Erfindung um sicherzustellen, dass der Host autorisiert ist, die IP-Adresse zu verwenden;
    Senden einer Aufgabe bzw. einer Infragestellung an den Host unter Verwendung der IP-Adresse als Zieladresse für die Aufgabe bzw. Infragestellung;
    Empfang einer Antwort von dem Host; und
    Verifizieren, dass die empfangene Antwort eine richtige Antwort hinsichtlich der Aufgabe bzw. Infragestellung ist.
  • In bevorzugter Weise weist diese Aufgabe bzw. Infragestellung eine zufällig erzeugte Zahl auf. Noch bevorzugter weist diese Aufgabe bzw. Infragestellung die IP-Adresse auf, die mit einer zufällig erzeugten Zahl verknüpft ist. Noch bevorzugter ist die Aufgabe bzw. Infragestellung durch Anwenden einer Ein-Wege-Codier-Funktion an die IP-Adresse, die mit einer zufällig erzeugten Zahl verknüpft ist, konstruiert.
  • In bevorzugter Weise weist die Antwort die Aufgabe bzw. Infragestellung auf. In noch bevorzugter Weise weist die Antwort die mit der Aufgabe bzw. Infragestellung verknüpfte IP-Adresse auf. Noch bevorzugter wird die Antwort durch Anwenden einer Ein-Wege-Codier-Funktion an die IP-Adresse, die mit der Aufgabe bzw. Infragestellung verknüpft ist, konstruiert.
  • Gemäß einem fünften Aspekt der vorliegenden Erfindung wird ein Verfahren zum Authentifizieren eines öffentlichen Schlüssels angegeben, welcher über ein IP-Netz von einem ersten zu einem zweiten Host übermittelt wird, wobei das Verfahren die folgenden Verfahrensschritte aufweist:
    Erzeugen eines Schnittstellen-Identifizierers beim ersten Host unter Verwendung des öffentlichen Schlüssels und Kombinieren des Schnittstellen-Identifizierers mit einem Leitwegelenkungs- bzw. Routing-Vorspann, um eine IP-Adresse für den ersten Host auszubilden;
    Senden des öffentlichen Schlüssels über das IP-Netz von dem ersten zu dem zweiten Knotenpunkt; und
    Verifizieren beim zweiten Knotenpunkt, dass der öffentliche Schlüssel der Schlüssel war, der erzeugt wurde, um den Schnittstellen-Identifizierer zu erzeugen.
  • Gemäß einem sechsten Aspekt der vorliegenden Erfindung wird ein Verfahren des Anbindens einer IP-Adresse an einen öffentlichen Schlüssel angegeben, wobei die IP-Adresse einen Leitwegelenkungs- bzw. Routing-Vorspann und ein Schnittstellen-Identifizierer-Teil aufweist, wobei das Verfahren die folgenden Verfahrensschritte aufweist:
    Erzeugen des Schnittstellen-Identifizierers durch Kombination von einer oder mehreren Komponenten und/oder Ableitungen der Komponenten unter Verwendung einer Codier-Funktion; und
    Erzeugen eines Zertifikats, welches mit einem privaten Schlüssel eines öffentlichen-privaten-Schlüsselpaares signiert ist, wobei das Zertifikat den Schnittstellen-Identifizierer und eine der Komponenten oder der Ableitungen oder weitere Ableitungen enthält, so dass das Zertifikat unter Verwendung des öffentlichen Schlüssels des Hosts authentifiziert werden kann und wobei der Besitz des Schnittstellen-Identifizierers durch Rekonstruktion des Schnittstellen-Identifizierers unter Verwendung der Inhalte des Zertifikates verifiziert werden kann, und Vergleich des Ergebnisses gegenüber dem echten Schnittstellen-Identifizierer.
  • Kurze Beschreibung der Zeichnungen
  • 1 zeigt schematisch ein Netzwerk, welches eine Anzahl von Hosts aufweist, die mit dem Internet verbunden sind;
  • 2 ist ein Ablaufdiagramm, welches einen Duplicate-Address-Detection-Prozess bzw. Zweitadressen-Erfassungs-Prozess in dem Netzwerk von 1 zeigt;
  • 3 ist ein Ablaufdiagramm, welches ein Verfahren zum Durchführen einer Anbindungs-Aktualisierung in dem Netzwerk von 1 darstellt.
  • Detaillierte Beschreibung bestimmter Ausführungsformen
  • In 1 wird ein Internet-Kommunikationsszenario dargestellt, in welchem eine Anzahl von Benutzerterminals oder Hosts 1 bis 4 mit dem Internet 5 verbunden sind. Die Hosts 1 bis 3 sind mit dem Internet 5 über einen Zugriffsknotenpunkt 6 eines Zugriffsnetzwerks 7 verbunden. Der Host 4 ist mittels eines Zugriffsnetzes, das nicht in der Figur gezeigt wird, verbunden.
  • Es sei angenommen, dass einer der Hosts 1 in dem Zugriffsnetzwerk 7 neu ist, und dass für diesen Host das Zugriffsnetzwerk ein fremdes Netzwerk ist (und. von daher ist der Zugriffsknotenpunkt 6 ein fremder Agent). Der Host 1 findet diese Tatsachen durch Empfang einer Router-Advertisement-Nachricht von dem fremden Agenten heraus (diese Nachricht kann eine durch den fremden Agenten periodisch verwendete Nachricht sein, oder sie kann an den Host 1 in Erwiderung auf eine Router-Solicitation-Nachricht, die an den fremden Agenten von dem Host 1 gesendet wird, gesendet werden). Der Host 1 lernt von der Router-Advertisement-Nachricht einen Leitwegelenkungs- bzw. Routing-Vorspann, der den fremden Agenten innerhalb des Internets eindeutig identifiziert. Der Host 1 sendet dann eine Einding-Update-Nachricht bzw. Anbindungs-Aktualisierungs-Nachricht an den Heimatagenten 8 von seinem Heimatnetzwerk 9 über den fremden Agenten 6, um den Heimatagenten bezüglich seines neuen Standortes zu informieren. Der Heimatagent antwortet durch das Senden einer Einding-Acknowledgement-Nachricht über den fremden Agenten 6 an den Host 1. Wie bereits obig erklärt, kombiniert der Host 1 den Leitwegelenkungs- bzw. Routing-Vorspann und einen Schnittstellen-Identifizierer, um eine IP-Adresse auszubilden.
  • Ein neues Verfahren zum Erzeugen von Schnittstellen-Identifizierer wird nun beschrieben. Dieses Verfahren weist verschiedene Vorteile auf, die folgendes aufweisen:
    • – Einbinden des Schnittstellen-Identifizierers an die Sicherungsschicht- bzw. Verbindungsschicht-Adresse;
    • – Einbinden des Schnittstellen-Identifizierers an einen öffentlichen Schlüssel;
    • – es stellt eine Einrichtung zur Verfügung, um eine Denial-of-Service-Attacke bzw. Dienstverweigerungs-Attacke während der Duplicate-Address-Detection bzw. Zweitadressen-Erfassung zu verhindern;
    • – es stellt eine Einrichtung zur Verfügung, um das „Adressen-Besitzverhältnis” aus einer Entfernung zu überprüfen.
  • Allgemeine Beschreibung des Schnittstellen-Identifizierers
  • Das beschriebene Verfahren basiert auf einer kryptographisch stabilen Ein-Wege-Codier-Funktion. Eine Ein-Wege-Codier-Funktion wird mit HASH(...) bezeichnet, und die hier verwendete, bestimmte Ein-Wege-Codier-Funktion ist SHA-1 (obwohl andere alternativ hierzu verwendet werden können). Sehr allgemein ausgedrückt, lautet das vorgeschlagene Verfahren zum Erzeugen eines Schnittstellen-Identifizierers:
    interface identifier:= HASH(component1|component2|component3)
    wobei „...|...” Konkatenation bzw. Dateienverknüpfung bezeichnet, wobei eine der Komponenten eine neu erzeugte („frische”) Zufallszahl ist und die anderen Komponenten Informationsteile sind, die der Knotenpunkt (oder Host), der den Schnittstellen-Identifizierer erzeugt, an den Schnittstellen-Identifizierer anbinden möchte.
  • Bei einem gegebenen Schnittstellen-Identifizierer ist es rechnerisch schwierig, einen Satz von Komponenten zu berechnen, deren Prüfsumme zu diesem Schnittstellen-Identifizierer-Wert gehört. Wenn der Schnittstellen-Identifizierer 64 Bit lang ist, dann sind 63 Bits hiervon in diesem Zusammenhang signifikant, im Durchschnitt dauert es (263)/2 = 264 Operationen, einen solchen Satz von Komponenten aufzufinden. Während es möglich sein kann, einen Hash-Wert dieser Länge mit heutzutage zur Verfügung stehenden Geräten aufzulösen, würde es in der Praxis leicht einige hundert Jahre dauern. Da angenommen wird, dass die Zufalls-Schnittstellen-Identifizierer eine relativ kurze Lebenszeit von in der Regel einigen Tagen haben, wirft dieses ein vernachlässigbares Risiko auf. Selbst wenn in Zukunft ein voraussichtliches Anwachsen der Verarbeitungsleistung angenommen wird (Verdoppelung alle 18 Monate), wird es viele Jahre dauern, bevor das Risiko bedeutend wird. Anstatt es zu versuchen, Komponenten mittels eines böswilligen Knotenpunktes zu jeder Zeit, wenn ein NS-Paket empfangen wird, zu berechnen, kann stattdessen dieser Knotenpunkt ausgewählt werden, vorberechnete Werte in einem Cache-Speicher aufzunehmen. Jedoch würde der für diese Aufgabe erforderliche Speicherplatz unerschwinglich werden.
  • Die Sicherheit des Verfahrens verlässt sich auf die Prämisse, dass keiner außer der Erzeuger des Schnittstellen-Identifizierers bei Bedarf die Werte der Komponenten schnell und auf einfache Weise bereitstellen kann. Selbstverständlich könnte ein Sicherheitslevel durch das Erzeugen des Schnittstellen-Identifizierers unter Verwendung von lediglich einer einzelnen Komponente bereitgestellt werden. Jedoch liefert das Verwenden mehrerer Komponenten andere Vorteile, wie es in den folgenden Abschnitten diskutiert wird.
  • Um von den mittels dieses Verfahrens des Erzeugens von Schnittstellen-Identifizierern bereitgestellten Vorteilen Gebrauch zu machen, müssen sämtliche der teilnehmenden Knotenpunkte einer „Abmachung” zustimmen. Diese Abmachung spezifiziert eine Anzahl von Angelegenheiten. Zunächst spezifiziert sie das Verfahren zum Erzeugen von Schnittstellen-Identifizierern. Ferner spezifiziert sie, dass, wenn ein Knotenpunkt die Komponenten bereitstellt, die verwendet werden, um einen Schnittstellen-Identifizierer zu erzeugen, dieser Knotenpunkt wahrscheinlicher diesen Schnittstellen-Identifizierer als ein Knotenpunkt, der diese Komponenten nicht bereitstellen kann, „besitzt”. Ferner spezifiziert sie die Struktur und die semantische Bedeutung der Komponenten, d. h. sie spezifiziert, dass eine der Komponenten eine Zufallszahl ist, und der Zweck der anderen Komponenten.
  • Anbinden des Schnittstellen-Identifizierers an die Sicherungsschicht- bzw. Verbindungsschicht-Adresse
  • In dem grundlegenden IETF-Dokument [RFC2373] wird die Sicherungsschicht- bzw. Verbindungsschicht-Adresse direkt verwendet, um den Schnittstellen-Identifizierer zu erzeugen. Das Ausführungsverfahren ist reversibel, was es ermöglicht, zu prüfen, dass eine Sicherungsschicht- bzw. Verbindungsschicht-Adresse und der Schnittstellen-Identifizierer einander entsprechen. Das heißt, bei einem gegebenen Schnittstellen-Identifizierer kann jeder die entsprechende Sicherungsschicht- bzw. Verbindungsschicht-Adresse konstruieren, und umgekehrt. Dieses ist innerhalb einer lokalen Verknüpfung nützlich. In einem nachfolgenden IETF-Dokument [RFC3041] ist jedoch diese Verknüpfung zerbrochen, um zu verhindern, dass die Sicherungsschicht- bzw. Verbindungsschicht-Adresse außerhalb der lokalen Verknüpfung gesendet wird und die Privatsphäre eines Hosts riskiert wird. Obwohl die Sicherungsschicht- bzw. Verbindungsschicht-Adresse verwendet wird, um den Schnittstellen-Identifizierer zu erzeugen, wird in der Praxis diese Information nicht verwendet. Das heißt, die Zufallszahl, die verwendet wird, um den neuen Schnittstellen-Identifizierer zu erzeugen, wird niemals veröffentlicht oder sonstwie verwendet. Von daher besteht keine Möglichkeit, von einem gegebenen Schnittstellen-Identifzierer auf die Sicherungsschicht- bzw. Verbindungsschicht-Adresse zu schließen, oder sogar herauszufinden, ob ein bestimmter Knotenpunkt (der durch die Sicherungsschicht- bzw. Verbindungsschicht-Adresse identifiziert wird) tatsächlich einen gegebenen Schnittstellen-Identifizierer erzeugt hat.
  • Das hier beschriebene Verfahren erzeugt teilweise die Verknüpfung zwischen der Sicherungsschicht- bzw. Verbindungsschicht-Adresse und dem Schnittstellen-Identifizierer neu. Wie bereits erläutert, wird der Schnittstellen-Identifizierer von verschiedenen Komponenten erzeugt, wobei (zumindest) einer von diesen nur dem erzeugenden Knotenpunkt anfänglich bekannt ist. Eine andere dieser Komponenten ist die Sicherungsschicht- bzw. Verbindungsschicht-Adresse. Wenn ein Knotenpunkt, der einen Schnittstellen-Identifizierer als eigen beansprucht, Komponenten offenbart (wie er es tun muss), die verwendet wurden, um den Schnittstellen-Identifizierer zu erzeugen, werden andere Knotenpunkte, die die offengelegten Komponenten lernen, automatisch die Sicherungsschicht- bzw. Verbindungsschicht-Adresse aus den Komponenten heraussuchen. Durch das Prüfen, dass die Prüfsumme der Komponenten tatsächlich mit dem Schnittstellen-Identifizierer übereinstimmt, bekommen sie eine relative Gewissheit, dass der Erzeuger des Schnittstellen-Identifizierers es tatsächlich wollte, die gegebene Sicherungsschicht- bzw. Verbindungsschicht-Adresse zu verwenden.
  • Um für das Anbinden des Schnittstellen-Identifizierers an die Sicherungsschicht- bzw. Verbindungsschicht-Adresse zu sorgen, genügt es, den Schnittstellen-Identifizierer durch
    Interface identifier := HASH(random|link layer address)
    zu erzeugen, wobei „random” eine frische Zufallszahl und „link layer address” die Sicherungsschicht- bzw. Verbindungsschicht-Adresse ist, die der erzeugende Knotenpunkt verwenden möchte.
  • Anbinden des Schnittstellen-Identifizierers an einen öffentlichen Schlüssel
  • Üblicherweise stellt das Unvermögen, eine IP-Adresse mit einem öffentlichen Schlüssel (oder einem anderen sicherheitsbezogenen Informationsteil) zu verknüpfen, ein schwerwiegendes Problem hinsichtlich der Sicherheit von verschiedenen IPv6-ähnlichen Signalisierungsmechanismen dar. Beispielsweise muss ein Knotenpunkt, der andere Knotenpunkte hinsichtlich eines Änderns der Routing- bzw. Leitwegelenkungs-Information für eine spezifizierte Adresse informieren möchte, zeigen, dass er die IP-Adresse „besitzt”.
  • Es wurden drei mögliche Quellen einer solchen Autorisation betrachtet. Als erstes kann die Autorisation lokal konfiguriert sein. Dieses funktioniert gut für kleine bis mittlere Netzwerke, die unter einer einzelnen Administration stehen. Als zweites gibt es einige Arten von globaler Infrastruktur, die einen Nachweis des Besitzes der IP-Adresse bereitstellen. Eine spezielle PKI, wie etwa eine auflösungssichere DNS, kann solch einen Dienst bereitstellen. Jedoch ist das Einrichten von solch einem Dienst in der Praxis sehr schwierig. Drittens kann die Autorisation auf gegenseitigen Abmachungen basieren. Dieses ist der sogenannte AAA-Ansatz, der von der IETF-AAA-Arbeitsgruppe avanciert wird. Jedoch nähert sich solch ein System asymptotisch dem globalen Infrastruktur-Fall an, wenn sein Versorgungsbereich expandiert, was zu Anzahl-Skalierbarkeit- und Vertrauens-Transitivitäts-Problemen führt. Zusammengefasst leiden diese sämtlichen drei Verfahren unter Skalierbarkeitseinschränkungen.
  • Ein viertes Verfahren, welches hier eingebracht wird, verwendet die Kryptographie und die Tatsache, dass der IPv6-Schnittstellen-Identifizierer-Teil einer IPv6-Adresse lang genug ist, einige kryptographische Signifikanz zu haben. Die Grundidee liegt darin, das komponentenbasierende Erzeugen des Schnittstellen-Identifizierers zu verwenden, um eine kryptographische Signifikanz-Verknüpfung zwischen dem Schnittstellen-Identifizierer und einem öffentlichen Schlüssel bereitzustellen. Das heißt, eine der bei der Erzeugung eines Schnittstellen-Identifizierers verwendeten Komponenten ist ein öffentlicher Schlüssel (oder die Kontrollsumme bzw. Prüfsumme des öffentlichen Schlüssels, d. h. der kryptographische Auszug oder „Fingerabdruck” des öffentlichen Schlüssels). Wie in dem Fall der Sicherungsschicht- bzw. Verbindungsschicht-Adresse stellt der Knotenpunkt durch Offenbarung der Komponenten einen Anspruch bereit, dass der Erzeuger des Schnittstellen-Identifizierers den bestimmten öffentlichen Schlüssel verwenden möchte. Von daher kann, wenn nur ein Schnittstellen-Identifizierer und die Komponenten, von welchen er erzeugt wurde, gegeben sind, jeder andere Knotenpunkt eine angemessene Gewissheit erhalten, dass der gegenwärtige Verwender des Schnittstellen-Identifizierers tatsächlich einen gegebenen kryptographischen Schlüssel verwenden möchte. Die entgegengesetzte Überprüfung, d. h., dass der Benutzer eines öffentlichen Schlüssels es wünscht, einen gegebenen Schnittstellen-Identifizierer zu verwenden, wird durch Signieren des Schnittstellen-Identifizierers mit dem Schlüssel bereitgestellt. Um diese Eigenschaften anzubieten, genügt es, den Schnittstellen-Identifizierer durch:
    interface identifier:= HASH(random|public key)
    zu erzeugen und ihn als
    certificate/signed message:= {interface identifier|public key}privatekey
    zu signieren, wobei „...|...” die Konkatenation bezeichnet, „{...}K” eine mit dem Schlüssel K signierte Nachricht bezeichnet, „random” eine frische bzw. neue Zufallszahl ist, „public key” der öffentliche Schlüssel oder eine kryptographische Kontrollsumme hiervon ist, und „private key” ein entsprechender privater Schlüssel ist. Für zusätzliche Gewissheit kann die Zufallszahl in die signierte Nachricht wie folgt eingebunden werden:
    certificate/signed message:= {interface identifier|random|public key}privatekey
  • Eine vollständige Schnittstellen-Identifizierer-Erzeugungs-Prozedur
  • Zum Zwecke der weiteren Darstellung der Erfindung und ihrer Anwendungen wird der folgende detaillierte Anwendungsvorschlag angegeben. Dieser verwendet sowohl die Sicherungsschicht- bzw. Verbindungsschicht-Adresse und einen öffentlichen Schlüssel, um den Schnittstellen-Identifizierer zu erzeugen.
  • Die folgenden Operatoren werden hier verwendet:
    • ...|...
    bezeichnet Konkatenation
    {...}K
    bezeichnet eine mit dem Schlüssel K signierte Nachricht.
    [...]K
    bezeichnet eine mit dem Schlüssel K verschlüsselte Nachricht.
    • 1. II0 sei ein 64-Bit Anfangs-Schnittstellen-Wert, der basierend auf der Sicherungsschicht- bzw. Verbindungsschicht-Adresse des Hosts genau wie im Anhang A von [RFC2373] spezifiziert erzeugt wird. Wenn solch ein Wert nicht vorliegt, muss II0 eine 64-Bit lange Nullfolge sein.
    • 2. Optional wird von einer autorisierten dritten Partei ein Schlüsselpaar <K+, K–> erzeugt oder erzielt, wobei K+ ein öffentlicher Schlüssel und K– ein entsprechender privater Schlüssel ist.
    • 3. Berechnung eines Auszuges eines öffentlichen Schlüssels, #K+: = HASH(K+). Wenn kein öffentlicher Schlüssel verwendet wird, muss #K+ ein Nullwert der gleichen Länge sein.
    • 4. Erzeugung eines anfänglichen Zufallswertes HN, wobei N die Länge der in dem nächsten Schritt zu erzeugenden Serie ist.
    • 5. Erzeugung einer Serie von Hash-Werten HN, ..., Hi, ... H0, wobei Hi-1: = HASH(Hi|II0|#K+) ist, durch n-maliges Anwenden der Funktion, d. h., bis H0 erzeugt ist.
    • 6. Der History-Keim H sei für den RFC3041
      Figure 00250001
      Schnittstellen-Identifizierer-Erzeugungsalgorithmus der letzte Wert in der Hash-Serie, d. h., H: = H0.
    • 7. Fortfahren wie im Abschnitt 3.2.1 von RFC3041 spezifiziert (mit geringfügigen Modifikationen) – Verknüpfe H|II0' wobei H der im Schritt 6 erzeugte History-Keim und II0' ein 64-Bit Nullwert* ist. – Berechne II': = MD5 (H|II0') – Nehme die äußersten 64 Bits des MD5-Auszuges II' heraus und setze Bit 6 auf 0. Das Ergebnis ist der Schnittstellen-Identifizierer II. – Wenn mehrere Versuche benötigt werden (d. h., aufgrund einer authentisierten Kollision), verwerfe den letzten Wert der Hash-Serie, wobei N um 1 vermindert wird: N:= N – 1, und fahre vom obigen Schritt 6 an fort. Es sei darauf hingewiesen, dass dieses verschieden von [RFC3041] ist, wo die MD5-Funktion einfach noch einmal angewendet wird.
    • 8. Wenn der optionale öffentliche Schlüsselwert in Schritt 2 erzeugt oder erzielt wurde, erzeuge ein selbstsignierendes Zertifikat, welches den Schnittstellen-Identifizierer, den Auszug des öffentlichen Schlüssels, die Anzahl der Werte in der Hash-Serie, den letzten Wert in der Hash-Serie und die Sicherungsschicht- bzw. Verbindungsschicht-Adresse des Hosts wie folgt enthält: CERT:= {II, #K+, N, H0}K–. Wenn der öffentliche Schlüssel nicht verwendet wird, muss ein leerer Wert verwendet werden, wann auch immer das CERT ansonsten verwendet werden würde. Die Verwendung von diesem Zertifikat wird nachfolgend beschrieben:
  • *) Der Grund, warum II0' anstelle II0 ist, ist zweifach. Einmal wurde II0 bei der Erzeugung der HN, ..., Hi, ... H0-Serien berücksichtigt, wobei auf mögliche schlechte Zufallszahlerzeugungen achtgegeben wird, wie es in RFC3041 durchdacht ist. Zusätzlich erfordert das Prüfen des Besitzes mit H1 ebenso II0, was es möglich macht, den Besitz mit der Sicherungsschicht- bzw. Verbindungsschicht-Adresse wie nachfolgend begründet lokal zu verknüpfen. Zweitens macht das Auslassen von II0 bei der Berechnung von II es möglich, anfänglich H nur an einem entfernten Knotenpunkt offenzulegen. Die Enthüllung bzw. Offenlegung von II0 über entfernte Verknüpfungen ist nicht gewünscht, da es effektiv die Datenschutzziele von RFC3041 annullieren würde.
  • In dem hier beschriebenen Verfahren ist der Besitz eines Schnittstellen-Identifizierers primär auf den erzeugten Hash-Serien und auf der Offenlegung früherer Werte von der Hash-Serie bei Bedarf basiert. Da der Bedarf gering sein sollte (nahezu nicht existierend, bis eine Attacke auftritt), scheint es für die meisten Hosts hinreichend zu sein. Jedoch wurde das Verfahren derart ausgelegt, dass der Schnittstellen-Identifizierer eng an einen kryptographischen Schlüssel gebunden ist, und der Schlüssel kann ebenso an den Schnittstellen-Identifizierer gebunden sein. Des weiteren bindet ebenso das Verfahren die Sicherungsschicht- bzw. Verbindungsschicht-Adresse in die Erzeugung des Schnittstellen-Identifizierers ein. Die Begründung lautet wie folgt:
    Wenn die Hash-Serie HN, ..., Hi, ... H0 konstruiert wird, werden in jedem Schritt sowohl die Sicherungsschicht- bzw. Verbindungsschicht-Adresse als auch eine Kontrollsumme eines öffentlichen Schlüssels verwendet. In Wirklichkeit zeigt dies, dass der Host den spezifizierten öffentlichen Schlüssel und die spezifizierte Sicherungsschicht- bzw. Verbindungsschicht-Adresse verwenden möchte, wenn er den Schnittstellen-Identifizierer verwendet. Dieses gestattet es lokal, dass die Knotenpunkte Pakete ignorieren, die von anderen Knotenpunkten unter Verwendung des Schnittstellen-Identifizierers des Knotenpunktes jedoch mit einer „falschen” Sicherungsschicht- bzw. Verbindungsschicht-Adresse gesendet werden. In Umgebungen, wo das Ändern der Sicherungsschicht- bzw. Verbindungsschicht-Adresse spezielle Privilegien oder Hardware-Operationen erfordert, steigert dies etwas die Sicherheit.
  • Die Einbeziehung des öffentlichen Schlüssels hat mehrere tiefsinnige Effekte. Im einzelnen bedeutet dies, dass die anderen Hosts direkt einen öffentlichen Schlüssel lernen können, so dass sie sicher den Besitzer eines Schnittstellen-Identifizierers zum Halten annehmen können. Das heißt, durch die Verwendung der Prüfsumme eines bestimmten öffentlichen Schlüssels in dem Schnittstellen-Identifizierer-Erzeugungs-Prozess hat der Knotenpunkt nachhaltig angedeutet, dass er möchte, dass der bestimmte Schnittstellen-Identifizierer den Schlüssel „besitzt”. Die umgekehrte Richtung wird mittels des selbstsignierenden Zertifikats gezeigt, das im wesentlichen angibt, dass der Besitzer von dem Schlüssel den Schnittstellen-Identifizierer „besitzen” möchte. Zusammen erzeugen diese beiden eine kryptographisch feste Zwei-Wege-Anbindung zwischen dem Schnittstellen-Identifizierer und dem öffentlichen Schlüssel. Tatsächlich scheint dies so nutzvoll zu sein, dass Hosts diese Information bei einer früheren Stufe unter Verwendung der Neighbour Solicitation-Nachrichten zu veröffentlichen möchten mögen, und dass sie es mögen, diese Information in ansuchenden Neighbour Advertisements erneut vortragen mögen. Aus diesem Grund können die Neighbour Solicitation (NS)- und Neighbour Advertisement (NA)-Nachrichten die folgende Information enthalten:
    • – Den öffentlichen Schlüssel K+ selbst.
    • – Das selbstsignierte Zertifikat CERT.
    • – Optional den Anfangs-Schnittstellen-Identifizierer II0.
  • Jedoch wird es für keinen anderen Zweck als zum Überprüfen der Sicherungsschicht- bzw. Verbindungsschicht-Adresse benötigt, und solch eine Überprüfung sollte möglichst nicht durchgeführt werden, bis der Besitz des Schnittstellen-Identifizierers verifiziert worden ist. Die Einbeziehung von K+ und CERT gestattet es dem empfangenden Host, zu verifizieren, dass der Besitzer des Schlüssels K+ wirklich den angegebenen Schnittstellen-Identifizierer verwenden möchte.
  • Der unter Verwendung dieses Verfahrens erzeugte Schnittstellen-Identifizierer hat viele Verwendungen, wobei einige von ihnen nun detailliert betrachtet werden.
  • Verhinderung der Dienstverweigerung während DAD
  • Während der Adressen-Autokonfiguration ist es möglich, dass der neu erzeugte Schnittstellen-Identifizierer mit einem bestehenden Schnittstellen-Identifizierer kollidiert. Dieses wird durch den Empfang eines Neighbour Advertisement-Pakets angezeigt, das beansprucht, dass irgendein anderer Knotenpunkt bereits den Identifizierer „besitzt”. In RFC3041 besteht das Verfahren, solch eine Kollision zu verhindern, darin, einen sukzessiven Schnittstellen-Identifizierer unter Verwendung von MD5 zu berechnen, und es maximal fünfmal wieder zu versuchen. Unglücklicherweise ist dieses Verfahren nicht wirksam gegenüber böswilligen Knotenpunkten, die einfach sämtliche Schnittstellen-Identifizierer beanspruchen.
  • Hash-basierende DoS-Vermeidung
  • Um zu verhindern, dass böswillige Knotenpunkte Schnittstellen-Identifizierer, die ein neuer Knotenpunkt erzeugt hat, als „Besitz” beanspruchen, wird vorgeschlagen, dass das DAD-Protokoll wie folgt erweitert wird:
    • a) Sämtliche Neighbour-Solicitation(NS)-Pakete weisen die Form <TA, C, K+, CERT> auf, wobei TA die provisorische Adresse, C eine Zufallszahl, K+ der öffentliche Schlüssel des antwortenden Knotenpunktes und CERT das im obigen Schritt 8 erzeugte Zertifikat ist. Streng gesprochen, werden die Zufallszahl (die als eine Aufgabe bzw. Infragestellung verwendet wird) und das Zertifikat nicht benötigt, jedoch tragen sie wenig Zuschlag und geringe Sicherheitssteigerung.
    • b) Eine Aufhebungs-NA-Nachricht, die als ein Teil von DAD gesendet wird, muss die folgende Form aufweisen: <TA, TLLA, i, Hi, #K+, R>, wobei TA die Adresse ist, deren Besitz die NA beansprucht, TLLA die Ziel-Sicherungsschicht- bzw. Verbindungsschicht-Adresse ist, II0 von TLLA wie im Anhang A von [RFC2373] spezifiziert berechnet wird, i der Zähler der verwendeten Hash-Werte (für die erste kollidierende NA ist i gleich 1) ist, Hi die i-te Kontrollsumme der Hash-Serie ist, #K+ der Auszug des öffentlichen Schlüssels ist (oder 128-Bit Nullwert, wenn die öffentliche Schlüssel-Verschlüsselung nicht verwendet wird) und R MD5(Hi|C) ist. Durch das Veröffentlichen dieser Werte zeigt der antwortende Knotenpunkt, dass er den Schnittstellen-Identifizierer „besitzt”. Wenn zusätzlich das optionale öffentliche Schlüsselpaar durch den antwortenden Knotenpunkt erzeugt oder erzielt wurde, wenn er den Schnittstellen-Identifizierer erzeugt, sollte die Nachricht den öffentlichen Schlüssel und eine Signatur enthalten, d. h. <TA, TLLA, i, Hi, #K+, R, K+, SIGN> , wobei K+ der im obigen Schritt 2 erzeugte öffentliche Schlüssel und SIGN eine Signatur über das gesamte Paket einschließlich der IP-Kopfzeile ist, die unter Verwendung von K– erzeugt wird.
  • Um zu verifizieren, dass der Host, der die NA sendet, wirklich den Schnittstellen-Identifizierer besitzt, berechnet der empfangende Host das folgende:
    • 1. Berechne H0 durch i-faches Berechnen von Hi-1: = HASH(Hi|II0|#K+)
    • 2. Setze H = H0
    • 3. Berechne II':= MD5(H|II0'), wobei II0' ein 64-Bit Nullwert ist
    • 4. Berechne II: = II' Bitwiseand 0xDFFFFFFFFFFFFFFF, was im wesentlichen Bit 6 von II' leert, wobei II hervorgebracht wird
    • 5. Überprüfe, dass TA = 0xfe80000000000000|II ist, wobei 0xfe80000000000000 der lokale Adressen-Vorspann der IPv6-Verknüpfung ist
    • 6. Überprüfe, dass R = MD5 (Hi|C) ist. Wenn des weiteren die NA die optionale Signatur enthält, dann kann der empfangende Host das folgende berechnen:
    • 7. Überprüfe, dass #K+ = HASH(K+) ist
    • 8. Überprüfe unter Verwendung von K+, dass SIGN eine gültige Signatur über das empfangene Paket ist.
  • Wenn beispielsweise i = 1 gilt, dann würde NA enthalten
    <TA, TLLA, 1, H1, #K+, TIME, K+, SIGN>
    und die Berechnung läuft wie folgt ab:
    • 1. H0: = HASH(H1|II0|#K+)
    • 2. H:= H0
    • 3. II':= MD5(H|64-Bit 0)
    • 4. II:= II' Bitwiseand 0xDFFFFFFFFFFFFFFF
    • 5. Überprüfe, dass TA = 0xfe80000000000000|II ist
    • 6. Überprüfe, dass R = MD5(Hi|C) ist
    • 7. Überprüfe, dass #K+ = HASH(K+) ist
    • 8. Überprüfe, dass SIGN = Signatur über das empfangene Paket ist.
  • Wenn die Überprüfungen durchgeht, dann kann der ansuchende Knotenpunkt annehmen, dass der Ansprechende wirklich den Schnittstellen-Identifizierer besitzt, und dass er einen neuen Schnittstellen-Identifizierer erzeugen sollte.
  • Es verbleibt jedoch eine Möglichkeit einer Wiedergabe-Attacke. Anstelle den Schnittstellen-Identifizierer als seinen Besitz zu beanspruchen, wenn der neue Knotenpunkt ihn erzeugt, kann ein Angreifer es gestatten, dass der Knotenpunkt den Schnittstellen-Identifizierer einrichtet, und er wirkt lediglich auf diesen ein. Sobald der Knotenpunkt seinen Besitz über den Schnittstellen-Identifizierer eingerichtet hat, sendet der Angreifer eine NS, die den Schnittstellen-Identifizierer abfragt bzw. anfordert. Gemäß diesem Protokoll muss der rechtmäßige Besitzer durch Offenlegung des soweit geheimen Wertes H1 entgegnen bzw. kontern, wodurch der Angreifer anfänglich abgeblockt wird. Jedoch kann der Angreifer nun erneut beanspruchen, den Schnittstellen-Identifizierer zu besitzen, dieses Mal durch einfaches Wiedergeben der NA, die die H1 aufdeckt. Der rechtmäßige Besitzer blockt diese Wiedergabe-Attacke durch Wiedergabe des vorhergehenden Hi-Wertes in der Hash-Serie ab. Soweit bekannt, ist die einzige Strategie, dieses Problem anzugehen, brutale Gewalt, die in der Größenordnung von 2(i-(Länge(Hi)-1))-Operationen benötigt, abhängig von der Länge des Wertes Hi. Wenn zusätzlich immer mehr als ein Paar von Hi-Werten aufgefordert werden, lokal aufgedeckt zu werden, ist es ein gutes Anzeichen eines Attackenversuches.
  • Dieses Verfahren wird ferner in dem Ablaufdiagramm in 2 dargestellt.
  • PK-basierende DoS-Vermeidung
  • Ein anderer, nicht verwandter Weg zum Lösen des Problems einer Wiedergabe-Attacke liegt in der Verwendung von einer der offengelegten und festgebundenen Komponenten. Das heißt, während zwei Knotenpunkte einen bestimmten Schnittstellen-Identifizierer durch das Bereitstellen der gleichen offengelegten Komponenten als „eigen” beanspruchen mögen, kann nur einer zeigen, dass er eine der Komponenten „besitzt”, und diese bestimmte Komponente kann verwendet werden, um den Konflikt zu lösen. Hier ist die Komponente, die verwendet wird, der öffentliche Schlüssel. Wenn von daher zwei Parteien beanspruchen, den gleichen Schnittstellen-Identifizierer durch das Aufzeigen der gleichen Komponenten zu besitzen (oder wenn die Komponenten bereits öffentlich gemacht wurden), kann der Streit durch einen der Anspruchsteller gelöst werden, der sein Vermögen zeigt, den privaten Schlüssel zu verwenden, welcher dem an den Schnittstellen-Identifizierer gebundenen öffentlichen Schlüssel entspricht.
  • Es gibt verschiedene Arten von öffentlicher Schlüssel-Kryptographie, einschließlich herkömmlicher öffentlicher Schlüssel-Verschlüsselungen, wie etwa RSA, öffentliche Schlüssel-Signatur-Algorithmen, wie etwa DSA, und selbst Null-Wissen-Protokolle bzw. Zero-Knowledge-Protokolle. Zum Zwecke des Überprüfens des Besitzes hinsichtlich eines Schnittstellen-Identifizierers ist jedes solcher Verfahren verwendbar. Das heißt, die einzigen Anforderungen liegen darin, dass es möglich ist, einen öffentlichen Schlüssel mittels eines kryptographischen Auszuges auszudrücken, und einen zeitlichen Nachweis zu bringen, dass der Anspruchsteller tatsächlich auf den privaten Schlüssel zugegriffen hat. Die gewöhnliche Art und Weise des Bereitstellens eines rechtzeitigen Nachweises liegt darin, ein Authentikations-Protokoll ablaufen zu lassen.
  • Sicherungsschicht- bzw. Verbindungsschicht-Adressen basierende DoS-Vermeidung
  • Abhängig von der Natur der verwendeten Sicherungsschicht- bzw. Verbindungsschicht-Kommunikation kann es ebenso möglich sein, die Sicherungsschicht- bzw. Verbindungsschicht-Adresse zu verwenden, um Konflikte zu lösen (und um sich gegen Wiedergabe-Attacken zu verteidigen), oder als die einzige Einrichtung zum lokalen Überprüfen des Besitztums des Schnittstellen-Identifizierers. Das heißt, wenn das verwendete Kommunikationsmedium sichere Sicherungsschicht- bzw. Verbindungsschicht-Adressen aufweist, dann ist die Möglichkeit, eine Sicherungsschicht- bzw. Verbindungsschicht-Adresse, wie obig diskutiert, an einen Schnittstellen-Identifizierer zu binden, hinreichend, um sicherzugehen, dass nur legitime Schnittstellen-Identifizierer verwendet werden.
  • Erweitern von Schnittstellen-Identifizierern auf leitwegelenkungsfähige Adressen
  • Bis jetzt wurden lediglich Schnittstellen-Identifizierer diskutiert. Wie jedoch in [RFC3041] spezifiziert, gelten zufällig erzeugte Schnittstellen-Identifizierer nur als lokal eindeutig. Von daher ist es möglich und sogar vermutlich, dass es kollidierende Schnittstellen-Identifizierer in dem globalen Internet gibt (gemäß dem „Geburtstags-Paradoxon” beträgt bei einem angenommenen Satz von etwa 2(63/2) oder etwa drei Billionen Schnittstellen die Wahrscheinlichkeit einer solchen Kollision etwa 50%). Selbst wenn wir durch das Voraussetzen von Eindeutigkeit in der (erweiterten) Duplicate Address Detection-Prozedur bzw. Zweitadressen-Erfassungs-Prozedur lokale Kollisionen nicht zulassen, müssen sie in dem nicht-lokalen Fall toleriert werden. Demzufolge ist es in dem nicht-lokalen Fall nicht sinnvoll, die Autorisation nur auf den Schnittstellen-Identifizierer zu basieren.
  • Anfrage bzw. Infragestellung/Erwiderung
  • Ein Grundproblem bei paketbasierender Kommunikation ist die Leichtigkeit des Beschwindelns der Quell-Adresse. Das heißt, außer wenn eine globale Zugangsfiltrierung verwendet wird, ist es einfach, Pakete zu verwenden, wobei die Quell-Adresse keine Relevanz aufweist. Ein Grundlevel von Sicherheit kann durch das Senden einer Aufgabe bzw. Infragestellung zurück an die in dem Paket spezifizierte Quell-Adresse und durch das Abwarten auf eine Antwort erzielt werden. Der Erzeuger des Paketes ist in der Lage, nur dann mit einer geeigneten Erwiderung zu antworten, wenn er in der Lage ist, Pakete zu empfangen, die an die Adresse gesendet werden. Dieses Verfahren ist wohlbekannt und wird beispielsweise in dem Cookie-Mechanismus in verschiedenen Protokollen verwendet.
  • Das grundlegende, nur auf Kontrollsummen basierende Verfahren zum Bereitstellen des Beweises des Schnittstellen-Identifizierers-Besitzes kombiniert den Infragestellungs-/Erwiderungs-Ansatz mit dem einfachen Ansatz der Offenbarung von Komponenten oder mit dem komplizierteren Ansatz der wiederholten Offenbarung von Komponenten (beide hiervon wurden obig beschrieben). Des weiteren wird die Kombination derart durchgeführt, dass die Partei, die den Besitz verifiziert, nicht umfangreiche Berechnungen durchführen muss. Die geringe Rechenintensität des Prozesses verhindert einige potentielle Ressourcen-aufreibende Dienstverweigerungs-Attacken.
  • Die Grundidee liegt darin, dass ein Anspruchsteller zunächst die zu prüfende Adresse verwendet, einschließlich des Schnittstellen-Identifizierers und der Komponenten, von welchen der Schnittstellen-Identifizierer erzeugt wurde. Dieses ist die erste Nachricht in dem Protokoll. Der Prüfer bzw. Verifizierer kann die Komponenten prüfen, wodurch er sicherstellt, dass der Anspruchsteller entweder den Schnittstellen-Identifizierer selbst erzeugt hat oder dass er ihn von dem Ursprungs-Knotenpunkt gelernt hat. Jedoch ist das Protokoll in der Art ausgelegt, dass die Anzahl der Knotenpunkte, die den zweiten Satz von Komponenten, die später verwendet werden, gelernt haben mag, wesentlich geringer ist, da wahrscheinlich eine große Anzahl von Knotenpunkten, die diesen ersten Satz von Komponenten gelernt haben, besteht.
  • Sobald der Prüfer den Schnittstellen-Identifizierer und die Komponenten geprüft hat, sendet er eine Infragestellung an die zu verifizierende Adresse. Im Prinzip könnte die Infragestellung eine einfache Zufallszahl sein. Jedoch wird hier die Zufallszahl mit dem zu verifizierenden Schnittstellen-Identifizierer und den Komponenten kombiniert, wodurch es gestattet wird, dass die gleiche Zufallszahl wiederholt verwendet wird. Die Infragestellung ist die zweite Nachricht in dem Protokoll. Wenn der Anspruchsteller die Infragestellung empfängt, erzeugt er eine Erwiderung. Die Erwiderung bildet die dritte und letzte Nachricht des Protokolls aus. Beim Erzeugen einer Erwiderung gibt es zwei mögliche Optionen:
    • a) Der Anspruchsteller verwendet den Schnittstellen-Identifizierer und den gleichen Satz von Komponenten, die er bereits in der ersten Nachricht offenbart hat interface identifier:= HASH(components) und versendet die Schnittstellen-Identifizierer und Komponenten (weil diese nicht durch den Prüfer zurückgehalten wurden).
    • b) Beim Erzeugen der Erwiderung verwendet der Anspruchsteller den Schnittstellen-Identifizierer und einen früheren Satz von Komponenten, d. h., einen Satz von Komponenten, der bei der Erzeugung der in der ersten Nachricht offengelegten Komponenten verwendet wurde interface identifier:= HASH(components1) components 1:= HASH(components2) und versendet den Schnittstellen-Identifizierer und components2.
  • Diese beiden Ansätze haben ihre Vor- und Nachteile. Der wesentliche Vorteil von a) liegt darin, dass der zweite Satz von Komponenten nicht offenbart zu werden braucht, wodurch dieser für die spätere Verwendung „gesichert” wird. Jedoch liegt der Nachteil darin, dass jeder, der den ersten Satz von Komponenten kennt, die Erwiderung erzeugen kann. Im Gegensatz hierzu macht in b) die Verwendung des zweiten Satzes von Komponenten den Satz von Komponenten zu öffentlicher Information. Nachdem sie einmal verwendet wurden, hat von daher jeder Host, der in der Lage ist, den ersten Satz von Komponenten zu lernen, höchstwahrscheinlich jedenfalls den zweiten Satz von Komponenten gelernt. Von daher liegt nahezu keine zusätzliche Sicherheit vor.
  • Das erste Verfahren a) wird hier bevorzugt, wo der gleiche Satz von Komponenten in der ersten und letzten Nachricht verwendet wird. Dieses Verfahren bietet die folgenden Zusicherungen an:
    • – Der Anspruchsteller ist in der Lage, Nachrichten zu empfangen, die an die Adresse gesendet werden, welche verifiziert wird. Diese Eigenschaft kann durch ein einfaches Aufgaben/Erwiderungs-Protokoll erzielt werden.
    • – Der Anspruchsteller hat entweder selbst den Satz von Komponenten erzeugt, von welchen der Schnittstellen-Identifizierer erzeugt wurde, oder er hat diese irgendwie gelernt.
  • Von daher liegt der hinzugefügte Sicherheitslevel (im Vergleich mit der grundsätzlichen Aufgabe/Erwiderung) in dem Bedarf, die Komponenten zu kennen (oder zu lernen). Unglücklicherweise ist das Erlernen der Komponenten nicht besonders schwer. Glücklicherweise funktionieren die Komponenten in dem hier beschriebenen Protokoll nur als eine erste Schutzschicht, und der tatsächliche Besitz wird nur durch die öffentliche Schlüsselkryptographie nachgewiesen.
  • Ein Angreifer kann die Komponenten durch zumindest drei verschiedene Verfahren gelernt haben. Er kann sie gelernt haben, weil er auf der gleichen lokalen Verknüpfung wie der Knotenpunkt, der die Komponenten erzeugt hat, liegt, weil er in der Lage ist, den Verkehr zwischen dem Knotenpunkt, der die Komponenten erzeugt hat, und einem anderen entfernten Knotenpunkt abzuhören, oder weil er sie von dem Ursprungsknotenpunkt durch das Ausführen von diesem äußersten Protokoll gelernt hat.
  • Wenn ein Angreifer die Komponenten gelernt hat, weil er auf der gleichen lokalen Verknüpfung wie der Erzeuger der Komponenten liegt, wird er es als schwierig empfinden, den Schnittstellen-Identifizierer zu verwenden. Der ursprüngliche Erzeuger der Komponenten wird noch immer als der Besitzer des Schnittstellen-Identifizierers betrachtet. Wenn der Angreifer versucht, Pakete mit dem gegebenen Schnittstellen-Identifizierer zu versenden, ist er auf einfache Weise nachweisbar. Wenn sich der Ursprungsknotenpunkt zu einer lokale Verknüpfung bewegt, oder wenn sich der Angreifer zu einer anderen lokalen Verknüpfung bewegt, ist die Situation ähnlich dem Fall, wenn der Angreifer die Komponenten durch das Abhören oder durch das Ablaufenlassen des Verifikations-Protokolls erlernt hat.
  • In dem anderen Szenario befinden sich der Angreifer und der tatsächliche Erzeuger der Komponenten auf verschiedenen Verknüpfungen. Von daher werden sie verschiedene Routing- bzw. Leitwegelenkungs-Vorpanne aufweisen. Da der Ursprungsknotenpunkt und der Angreifer verschiedene leitweglenkbare Adressen aufweisen, kann nun der Angreifer, der den gleichen Schnittstellen-Identifizierer wie der Ursprungsknotenpunkt verwendet, als ein Angreifer angesehen werden. Der Angreifer wird in der Lage sein, das grundsätzliche Aufgabe/Erwiderungs-Protokoll, wie es in diesem Abschnitt beschrieben wird, ablaufen zu lassen, jedoch wird es und sollte es nicht viel helfen.
  • Dieses Verfahren ist ferner in dem Ablaufdiagramm von 3 dargestellt.
  • Kombination der Aufgabe/Erwiderungs- und auf öffentlichem Schlüssel basieren Authentikation
  • In dem lokalen Fall war die Fragestellung sehr stark auf die Eindeutigkeit des Schnittstellen-Identifizierers gerichtet. Wie bereits diskutiert, müssen im globalen Fall Schnittstellen-Identifizierer nicht eindeutig sein, und sie sind es im allgemeinen nicht. Von daher gibt es keinen Punkt, der versucht, dieses sicherzustellen oder zu überprüfen. Auf ähnliche Weise hat die Sicherungsschicht- bzw. Verbindungsschicht-Adresse keine Relevanz in dem globalen Ausmaß. Statt dessen ist die Möglichkeit, einen öffentlichen Schlüssel und einen Schnittstellen-Identifizierer miteinander fest zu verbinden, sehr wichtig. Da jedoch Operationen hinsichtlich des öffentlichen Schlüssels, wie etwa das Erzeugen von Signaturen und die Verifikationen von Signaturen, sehr aufwendig sind, ist ein bevorzugtes Verfahren ein Verfahren, wo zunächst die Ein-Wege-Codier-Funktionen als die „Frontbarriere” verwendet wird, welches Angriffe schwieriger macht, und Funktionen hinsichtlich des öffentlichen Schlüssels werden nur danach verwendet. Die Verwendung von Funktionen hinsichtlich des öffentlichen Schlüssels kann direkt Möglichkeit eröffnen für Ressourcen-erschöpfende Dienstverweigerungs-Attacken
  • In dem auf dem öffentlichen Schlüssel basierenden Verfahren verwendet der Anspruchsteller zunächst ein Paket, welches die zu verifizierende Adresse einschließlich des Schnittstellen-Identifizierers und der Komponenten, von welchen der Schnittstellen-Identifizierer erzeugt wurde, enthält. Jedoch enthalten diese Komponenten noch nicht irgendeine Information hinsichtlich des öffentlichen Schlüssels des Anspruchstellers, da von dem Prüfer bzw. Verifizierer nicht erwartet wird, einen Zustand oder eine andersartige Erinnerung zu erzeugen, dass er jemals diese erste Nachricht empfangen hat. Der Prüfer erzeugt eine Aufgabe bzw. Infragestellung wie zuvor. Jedoch kann er zusätzlich zu der Aufgabe bzw. Infragestellung seinen öffentlichen Schlüssel an den Anspruchsteller als ein zusätzliches Informationsteil versenden. In diesem Fall wird der öffentliche Schlüssel am besten als ein selbstsigniertes Zertifikat versendet. Es wird erwartet, dass der Prüfer dieses Zertifikat fertig hat, so dass das Senden hiervon lediglich das Anhängen von diesem an die Nachrichten erfordert.
  • Der nächste Schritt schließt verschiedene Optionen ein, abhängig davon, was erforderlich ist. Wenn der Prüfer seinen öffentlichen Schlüssel anbietet, kann der Anspruchsteller ihn verwenden. In jedem Fall muss der Anspruchsteller seinen eigenen privaten Schlüssel bei der Aufgabe bzw.
  • Infragestellung verwenden, um eine vielgeschichtete Erwiderung effektiv zu erzeugen. Das heißt, der Anspruchsteller zeigt, dass er tatsächlich in der Lage war, die Aufgabe bzw. Infragestellung zu empfangen, und er richtet sich nach dieser. Es muss sehr „billig” für den Prüfer sein, dieses zu verifizieren, da ansonsten ein Angreifer falsche Erwiderungsnachrichten senden kann, wobei die Verarbeitung von diesen viele Betriebsmittel bzw. Ressourcen von dem Prüfer verbrauchen würde.
  • Eine weitere Sicherungsschicht wird dann unter Verwendung des öffentlichen Schlüssels erzeugt. Hier muss der Prüfer zunächst in der Lage sein, zu überprüfen, dass tatsächlich eine Bindung zwischen dem Schnittstellen-Identifizierer und dem öffentlichen Schlüssel besteht. Sobald jedoch die Information über den öffentlichen Schlüssel an den Prüfer übergeben ist, gibt es verschiedene Standard-Optionen, wie dieser zu verwenden ist.
  • Zusammengefasst weist das Verfahren folgende Sicherungsschichten auf:
    • 0.1. Der Prüfer kann selbst vor dem Senden einer Aufgabe bzw. Infragestellung sehr günstig verifizieren, dass der Anspruchsteller einen Satz von Komponenten kennt, die dem Schnittstellen-Identifizierer entsprechen.
    • 0.2. Der Prüfer ist in der Lage, eine Aufgabe bzw. Infragestellung auf günstige Weise zu konstruieren, ohne die Zustandinformation sichern zu müssen.
    • 1.1. Der Prüfer kann auf günstige Weise verifizieren, dass der Anspruchsteller in der Lage war, die Aufgabe bzw. Infragestellung zu empfangen.
    • 1.2. Der Prüfer kann auf günstige Weise verifizieren, dass der Anspruchsteller noch immer den gleichen Satz von Komponenten kennt, die in der ersten Nachricht versendet wurden.
    • 2.1. Der Prüfer kann auf günstige Art verifizieren, dass der durch den Anspruchsteller gegebene öffentliche Schlüssel tatsächlich eine der Komponenten ist, die bei der Erzeugung des Schnittstellen-Identifizierers verwendet wurden.
    • 2.2. Der Prüfer kann (aufwendig) verifizieren, dass der Anspruchsteller den privaten Schlüssel besitzt, der zu dem öffentlichen Schlüssel gehört.
  • Detaillierte Protokoll-Beschreibung
  • Der Mechanismus wird im Hinblick auf Alice und Bob beschrieben, wobei Bob Alice beweisen möchte, dass er die IP-Adresse TA „besitzt”. Das nachfolgende Drei-Nachrichten-Protokoll wird verwendet. Zusätzlich wird ein 0-Schritt benötigt, um zu spezifizieren, wie Bob die Adresse erzeugt hat.
    • 0. Bob erzeugt eine neue IP-Adresse TA unter Verwendung des obig dargestellten Verfahrens.
    • 1. Bob möchte Alice beweisen, dass er die Adresse TA besitzt. Um dieses zu tun, sendet er Alice eine Nachricht, die das folgende enthält: MSG1 = <TA, H0, #K+, N> , wobei: – TA die IP-Adresse ist, deren Besitz Bob beweisen möchte, die sich aus einem Routing- bzw. einem Leitwegelenkungs-Vorspann RP und einem Schnittstellen-Identifizierer II zusammensetzt, – H0 ist das H0, welches Bob während der Erzeugung von II verwendete, – #K+ ist eine Prüfsumme eines öffentlichen Schlüssels, den Bob während der Erzeugung von H0 verwendete, und – N ist eine Zufallszahl (einstweilig), welche Bob verwenden kann, um die Erwiderung zu identifizieren, die er erwartet, von Alice zu empfangen. Da N irgendeine Zahl sein kann, kann Bob irgendeine Zahl, beispielsweise 0, verwenden, wenn Bob nicht eine Zufallszahl verwenden möchte.
    • 2. Alice empfängt das Paket und sendet eine Aufgabe bzw. Infragestellung.
    • 2.1. Alice prüft, dass interface_identifier (TA) = MD5 (H0|64-Bit 0) Bitwiseand 0xDFFFFFFFFFFFFFFF. Dieses beweist, dass Bob den richtigen Wert von H0 kennt, entweder, weil er ihn selbst erzeugt hat, oder weil er ihn durch Abhören oder durch das Ausführen des bestimmten Protokolls zuvor erlernt hat. Bereits dieses kann als ein schwacher Beweis des Besitzes des Schnittstellen-Identifizierers betrachtet werden.
    • 2.2. Alice erzeugt eine Aufgabe bzw. Infragestellung C:= MD5(P|H0|#K+|N|TA) , wobei P eine Zufallszahl (eine einstweilige) ist. Eine einzelne einstweilige wird für verschiedene Aufgaben bzw. Infragestellungen dienen, und von daher braucht Alice nicht einen Zustand zu erzeugen.
    • 2.3. Alice versendet ein Paket an die Adresse TA, wobei das Paket die Aufgabe bzw. die Infragestellung C enthält. Es ist wichtig, darauf hinzuweisen, dass diese Nachricht an die Adresse TA gesendet wird, da sie prüft, dass Bob durch TA erreichbar ist. Optional kann das Paket ebenso das von Alice selbst signierte Zertifikat CERTA = {IIA, #KA+, NA, HA,0}KA– enthalten. MSG2 = <N,C> oder MSG2 = <N, C, KA+, CERTA>
    • 3. Bob empfängt die Aufgabe bzw. Infragestellung und sendet eine Erwiderung.
    • 3.1. Optional prüft Bob N, um zu sehen, dass die Aufgabe bzw. Infragestellung tatsächlich in einer Erwiderung auf sein anfängliches Paket gesendet wurde.
    • 3.2. Bob berechnet die Erwiderung R:= MD5(C|TA|H0|#K+|N).
    • 3.3. Optional extrahiert Bob den öffentlichen Schlüssel KA+ von Alice und prüft CERTA. Zunächst verifiziert Bob das folgende: – IIA stimmt mit dem Schnittstellen-Identifizierer überein, den Alice als Quell-IP-Adresse in der IP-Kopfzeile verwendete, als sie MSG2 sendete. – IIA = MD5(H0|64-bit 0) Bitwiseand 0xDFFFFFFFFFFFFFFF – #KA+ = HASH (KA+) – CERTA enthält #KA+ – CERTA ist gültig signiert Wenn diese Verifikation fehlschlägt, fährt Bob fort, als ob die optionalen Teile KA+ und CERTA insgesamt nicht empfangen wurden.
    • 3.4. Wenn Bob den öffentlichen Schlüssel von Alice und die Verifikation in Schritt 3.3. erfolgreich empfangen hat, bereitet Bob einen Sicherheitsschlüssel vor, der zwischen ihm und Alice geteilt bzw. gemeinsam verwendet wird. – Erzeugen eines symmetrischen Sicherheitsschlüssels KAB, der von Alice und Bob gemeinsam verwendet wird. – Verschlüsseln einer Nachricht unter Verwendung des öffentlichen Schlüssels von Alice, die den neu erzeugten Schlüssel KAB, das II0, welches Bob bei der Erzeugung von H0 verwendete und das H1, welches Bob bei der Erzeugung von H0 verwendete, enthält. Dieses ist der Sicherheitsteil S, den nur Alice wird öffnen können. – S:= [II0, KAB, H1]KA+ Wenn S nicht erzeugt wird, wird es durch eine leere Zeichenkette ersetzt.
    • 3.5. Bob sendet ein Paket an Alice, welches die Erwiderung R enthält. Zusätzlich muss diese Nachricht die gleiche TA, H0, #K+ und N enthalten, wie MSG1 es enthielt. MSG3 = <TA, H0, #K+, N, R, S> Optional kann die Nachricht ebenso den öffentlichen Schlüssel K+ von Bob, das Zertifikat CERT und die Signatur SIGN enthalten. MSG3 = <TA, H0, #K+, N, R, S, K+, CERT, SIGN> Die Signatur SIGN ist eine Signatur über den Rest der Nachricht, die unter Verwendung von dem privaten Schlüssel K– von Bob erzeugt wird.
    • 4. Alice empfängt die Erwiderung und prüft diese.
    • 4.1. Da Alice keinen Zustand gesichert hat, wird sie zunächst erneut überprüfen, dass der Schnittstellen-Identifizierer hinsichtlich H0 gültig ist. interface_identifier (TA) = MD5(H0|64-bit 0) Bitwiseand 0xDFFFFFFFFFFFFFFF. Wenn dieses nicht gehalten wird, verwirft Alice einfach das Paket.
    • 4.2. In Kenntnis von P, berechnet Alice erneut C unter Verwendung von Information von der empfangenen Nachricht C': = MD5(P|H0|#K+|N|TA) und prüft, dass die Erwiderung R den erwarteten Wert R = MD5(C'|TA|H0|#K+|N) aufweist. Wenn dieses nicht gehalten wird, nimmt sie an, dass der Anspruch von Bob nicht gültig ist. Andererseits ist ein gültiger Anspruch ein Beweis, dass Bob in der Lage ist, Pakete zu empfangen, die an TA gesendet werden.
    • 4.3. Wenn die Nachricht den optionalen Teil enthalten hat, d. h., den öffentlichen Schlüssel K+ von Bob, sein Zertifikat CERT und die entsprechende Signatur SIGN, prüft Alice das folgende: – II in CERT stimmt mit dem Schnittstellen-Identifizierer von TA überein – #K+ = HASH(K+) – CERT enthält #K+ – CERT ist gültig signiert – die Signatur SIGN ist gültig Dieses beweist, dass der Besitzers des Schlüssels K+ die Adresse TA verwenden möchte und dass Bob den Schlüssel K+ besitzt, da er K– kennt.
    • 4.4. Wenn die Nachricht den Sicherheitsteil S enthält, entschlüsselt Alice S unter Verwendung ihres privaten Schlüssels KA–, wobei II0, KAB und H1 offengelegt werden. Alice prüft das folgende: II = MD5(HASH(H1|II0|#K+) Dieses beweist, dass der Erzeuger von II einen öffentlichen Schlüssel verwenden wollte, dessen Auszug #K+ ist, und dass er eine Sicherungsschicht- bzw. Verbindungsschicht-Adresse aufweist, die mit II0 übereinstimmt. Dieses schließt die Schleife von II zu K+ und zurück von K+ auf II. Die Tatsache, dass II0 aufgedeckt ist, ist nicht grundsätzlich ein Problem, da die Nachricht verschlüsselt ist.
  • Wenn alles von dem Protokoll bestätigt ist, einschließlich des optionalen Schrittes 4.3., hat Alice gelernt, dass Bob gegenwärtig bei TA erreichbar ist, und dass K+ der öffentliche Schlüssel ist, den Bob verwendete, um TA zu erzeugen. Zusätzlich weiß Alice, dass die Sicherungsschicht- bzw. Verbindungsschicht-Adresse von Bob II0 ist, jedoch macht sie nicht viel mit dieser Information.
  • Zusammengefasst sind die Vorzüge der dargestellten Schemata die folgenden:
    • – Die starke Bindung zwischen der Sicherungsschicht- bzw. Verbindungsschicht-Adresse und dem Schnittstellen-Identifizierer, wie in [RFC2373] spezifiziert und in [RFC3041] eingebrochen, wird teilweise auf eine Art erzeugt, die nicht die Ziele hinsichtlich der Privatsphäre von [RFC3041] beeinträchtigt.
    • – Eine neue Bindung bzw. Verknüpfung von einem Schnittstellen-Identifizierer zu einem öffentlichen Schlüssel wird erzeugt.
    • – Eine Einrichtung, eine Dienstverweigerungs-Attacke während der IPv6-Autokonfiguration [RFC2462] zu blockieren, wird der Duplicate Adress Detektion (DAD) bzw. Zweitadressen-Erfassungs-Prozedur hinzugefügt.
    • – Eine Einrichtung, um den Besitz eines Schnittstellen-Identifizierers zum Zwecke des Modifizierens lokaler Leitwegelenkungs- bzw. Routing-Information zu „prüfen”, wie es beispielsweise bei Verknüpfungsaktualisierungen von mobilen IPv6 erforderlich ist, ist dargestellt.
  • Bestimmte Schlüsseleigenschaften der Schemata sind wie folgt:
    • – Durch das Ausbilden des Schnittstellen-Identifizierer-Teils einer IPv6-Adresse durch das Anwenden einer Ein-Wege-Funktion an Komponenten, wobei zumindest eine von diesen anfänglich sicher ist, ist eine spätere Offenbarung dieser Komponenten gestattet, um als ein Beweis des Besitzes des Schnittstellen-Identifizierers zu dienen.
    • – Es wird vorgeschlagen, die Ein-Wege-Funktion mehrmals an den Komponenten anzuwenden, wodurch Sicherheit gegenüber Attacken bereitgestellt wird, wenn ein Angreifer zuvor offenbarte Komponenten verwendet.
    • – Durch das Ausbilden des Schnittstellen-Identifizierer-Teils einer IPv6-Adresse durch das Anwenden einer Ein-Wege-Funktion an Komponenten durch das Spezifizieren semantischer Bedeutung zu diesen Komponenten und durch das Offenbaren dieser Komponenten ist es dem Schnittstellen-Identifizierer gestattet, als ein kryptographisches Kürzel zu dienen, der Werte für semantisch signifikante Komponenten angibt im Namen des Benutzers des Schnittstellen-Identifizierers.
    • – Im einzelnen kann die Sicherungsschicht- bzw. Verbindungsschicht-Adresse eine der verwendeten semantisch bedeutungsvollen Komponenten sein. Die Sicherheitsrelevanz des Einführens der Sicherungsschicht- bzw. Verbindungsschicht-Adresse hängt von der einzelnen Implementation bzw. Verwendung der lokalen Verknüpfung ab.
    • – Im einzelnen kann ein öffentlicher Schlüssel oder ein Nachrichten-Auszug eines öffentlichen Schlüssels eine der verwendeten, semantisch bedeutungsvollen Komponenten sein. Potentiell hat dieses sehr starke Sicherheitskonsequenzen, da es gestattet, dass ein Schlüssel und eine IPv6-Adresse verknüpft werden ohne irgendeine externe Infrastruktur, wie etwa eine PKI- oder eine AAA-Infrastruktur.
    • – Durch das Kombinieren des bekannten Aufgaben/Erwiderungs-Verfahrens bei der Prüfung der Erreichbarkeit mit der Möglichkeit, einen öffentlichen Schlüssel an einen Schnittstellen-Identifizierer zu binden, wird es möglich, über das Internet zu prüfen, dass jemand, der beansprucht, Kontrolle über einen bestimmten Schnittstellen-Identifizierer zu haben, wirklich mit hoher Wahrscheinlichkeit diese Kontrolle hat.
    • – Durch Kombinieren der wiederholten Erzeugung des Schnittstellen-Identifizierers von Komponenten ist es gestattet, die Prüfung des Besitzes von einem Schnittstellen-Identifizierer derart durchzuführen, dass der Prüfer einen gewissen Schutz gegenüber einer Ressourcen- bzw. Betriebsmittel-erschöpfenden Dienstverweigerung hat. Dieser DoS-Schutz wird durch Einschränkung der Anzahl der Knotenpunkte, die den Prüfer veranlassen könnten, aufwendige Berechnungen hinsichtlich des öffentlichen Schlüssels durchzuführen, erzeugt.
  • Es wird ersichtlich sein, dass verschiedene Modifikationen an den obig beschriebenen Ausführungsformen, ohne von dem Umfang der vorliegenden Erfindung abzuweichen, durchgeführt werden können.

Claims (22)

  1. Verfahren zum Verifizieren, dass ein an ein IP-Netz angeschlossener Host autorisiert ist, eine IP-Adresse zu verwenden, welche der Host als eigen beansprucht, wobei die IP-Adresse einen Routing- bzw. Leitwegelenkungs-Vorspann und einen Schnittstellen-Identifizierer-Teil aufweist, wobei das Verfahren folgende Verfahrensschritte aufweist: – Empfang von einer oder mehreren Komponenten von dem Host; – Anwenden einer Ein-Wege-Codier-Funktion an der oder an jeder Komponente und/oder Ableitungen von der oder von jeder Komponente; und – Vergleich des Ergebnisses oder einer Ableitung des Ergebnisses gegenüber dem Schnittstellen-Identifizierer-Teil der IP-Adresse, wobei, wenn das Ergebnis oder seine Ableitung mit dem Schnittstellen-Identifizierer übereinstimmt, der Host als autorisiert gilt, die IP-Adresse zu verwenden, und wenn das Ergebnis oder seine Ableitung nicht mit dem Schnittstellen-Identifizierer übereinstimmt, der Host als nicht autorisiert gilt, die IP-Adresse zu verwenden.
  2. Verfahren gemäß Anspruch 1, wobei die Komponenten einen Hash-Wert aufweisen, der ein Hash-Wert einer Sequenz von Hash-Werten ist.
  3. Verfahren gemäß Anspruch 1 oder 2, wobei die Komponenten einen öffentlichen Schlüssel oder einen Auszug eines mittels des Hosts erzeugten oder mittels des Hosts von einer anderen autorisierten Partei erzielten öffentlichen Schlüssels, oder eine feste Bit-Sequenz der gleichen Länge aufweisen.
  4. Verfahren gemäß Anspruch 1, 2 oder 3, wobei die Komponenten einen Anfangs-Schnittstellen-Identifizierer, welcher einer Sicherungsschicht- bzw. Verbindungsschicht-Adresse des Hosts entspricht oder welcher von einer Sicherungsschicht- bzw. Verbindungsschicht-Adresse des Hosts abgeleitet ist, oder eine feste Bit-Sequenz der gleichen Länge aufweisen.
  5. Verfahren gemäß einem der vorhergehenden Ansprüche, wobei die Komponenten einen Anfangs-Schnittstellen-Identifizierer, der einer Sicherungsschicht- bzw. Verbindungsschicht-Adresse des Hosts entspricht oder der von einer Sicherungsschicht- bzw. Verbindungsschicht-Adresse des Hosts abgeleitet ist, oder eine Null-Bit-Sequenz der gleichen Länge aufweisen.
  6. Verfahren gemäß Anspruch 2 oder einem der Ansprüche 3 bis 5, wobei, wenn abhängig von Anspruch 2, die Komponenten einen Zählerwert aufweisen, welcher die Position des empfangenen Hash-Wertes in der Sequenz identifiziert.
  7. Verfahren gemäß Anspruch 2, wobei die Serien der Hash Werte bei dem Host durch Anwenden einer Ein-Wege-Codier-Funktion an einem Keim-Wert und einem öffentlichen Schlüssel oder einem Auszug des öffentlichen Schlüssels abgeleitet werden.
  8. Verfahren gemäß Anspruch 2, wobei die Serien der Hash-Werte bei dem Host durch Anwenden einer Ein-Wege-Codier-Funktion an einem Keim-Wert und einem Anfangs Schnittstellen-Identifizierer abgeleitet werden.
  9. Verfahren gemäß Anspruch 2 oder gemäß einem der Ansprüche 3 bis 9 soweit abhängig von Anspruch 2, wobei ein Hash-Wert von dem empfangenen Hash-Wert abgeleitet wird, um eine Ableitung zu erhalten, an welcher die Ein-Wege-Codier-Funktion angewandt wird, wobei der abgeleitete Hash-Wert der letzte Hash-Wert in der Sequenz ist.
  10. Verfahren gemäß Anspruch 2, wobei die Serien der Hash-Werte bei dem Host durch Anwenden einer Ein-Wege-Codier-Funktion an einem Keim-Wert, einem öffentlichen Schlüssel oder einem Auszug des öffentlichen Schlüssels, und an einem Anfangs-Schnittstellen-Identifizierer abgeleitet werden.
  11. Verfahren gemäß Anspruch 10, wobei in dem Fall einer ersten IP-Adressen-Verifikation der von dem Host empfangene Hash-Wert der Hash-Wert ist, der dem letzten Hash-Wert in der Sequenz vorangeht, und wobei für jeden nachfolgenden Verifikationsprozess der nächst frühere Hash-Wert empfangen Werden muss.
  12. Verfahren zum Erzeugen einer IP-Adresse bei einem Host, wobei die IP-Adresse einen Leitwegelenkungs- bzw. Routing-Vorspann und einen Schnittstellen-Identifizierer-Teil aufweist, wobei das Verfahren folgende Verfahrensschritte aufweist: – Erzeugen einer Sequenz von Hash-Werten durch Anwenden einer Prüfsummen-Funktion an zumindest einem Zufallswert und durch iteratives Anwenden der Prüfsummen-Funktion auf das Ergebnis; und – Erzeugen des Schnittstellen-Identifizierer-Teils durch Anwenden einer Ein-Wege-Codier-Funktion auf eine oder mehrere Komponenten, wobei die Komponenten den letzten der Sequenz von Hash-Werten aufweisen, und wobei die Hash-Werte, die dem letzten Hash-Wert vorausgehen, nicht zuvor verwendet wurden, um eine IP-Adresse zu erzeugen.
  13. Verfahren gemäß Anspruch 12, wobei der erste Hash-Wert durch Anwenden einer Ein-Wege-Codier-Funktion an einer Kombination der Zufallszahl und eines Anfangs-Schnittstellen-Identifizierers erzeugt wird.
  14. Verfahren gemäß Anspruch 12, wobei der erste Hash-Wert durch Anwenden einer Ein-Wege-Codier-Funktion an einer Kombination der Zufallszahl und eines öffentlichen Schlüssels oder eines Auszuges des öffentlichen Schlüssels erzeugt wird.
  15. Verfahren gemäß Anspruch 12, wobei der erste Hash-Wert durch Anwenden einer Ein-Wege-Codier-Funktion an einer Kombination der Zufallszahl, eines Anfangs-Schnittstellen-Identifizierers und eines öffentlichen Schlüssels oder eines Auszuges des öffentlichen Schlüssels erzeugt wird.
  16. Verfahren zum Verhindern des Duplizierens von IP-Adressen in einem IP-Netz, wenn ein neuer Host an das Netz angebunden wird, wobei das Verfahren die folgenden Verfahrensschritte aufweist: – Erzeugen eines Schnittstellen-Identifizierers bei dem neuen Host durch Kombinieren einer Komponente oder mehrerer Komponenten und/oder Ableitungen der Komponente oder der Komponenten unter Verwendung einer Ein-Wege-Codier-Funktion, und durch Verwenden des Ergebnisses oder einer Ableitung des Ergebnisses als Schnittstellen-Identifizierer, wobei der Schnittstellen-Identifizierer einen Teil der IP-Adresse ausbildet; – Senden einer Neighbour-Solicitation-Nachricht bzw. Nachbar-Ansuchungs-Nachricht von dem neuen Host zu anderen Hosts, die bereits an das Zugriffsnetz angebunden sind; – Empfang einer Neighbour-Advertisement-Nachricht bzw. Nachbar-Ankündigungs-Nachricht bei dem neuen Host von jedem anderen Host, der die IP-Adresse als eigen beansprucht, wobei die oder jede Neighbour-Advertisement-Nachricht bzw. Nachbar-Ankündigungs-Nachricht die Komponenten bzw. die Komponente enthält; und für jede empfangene Nachbar-Ankündigungs-Nachricht: – Kombinieren der Komponente bzw. der Komponenten und/oder der Ableitungen der Komponente bzw. der Komponenten unter Verwendung der Codier-Funktion; und – Vergleich des Ergebnisses oder einer Ableitung des Ergebnisses gegenüber dem Schnittstellen-Identifizierer-Teil der IP-Adresse, wobei, wenn das Ergebnis oder die Ableitung mit dem Schnittstellen-Identifizierer übereinstimmt, der Host, von welchem die Neighbour-Advertisement-Nachricht bzw. Nachbar-Ankündigungs-Nachricht empfangen wird, als autorisiert gilt, die IP-Adresse zu verwenden, und wobei, wenn das Ergebnis oder seine Ableitung nicht mit dem Schnittstellen-Identifizierer übereinstimmt, dieser Host als nicht autorisiert gilt, die IP-Adresse zu verwenden.
  17. Verfahren zum Verifizieren, dass ein an ein IP-Netz angeschlossener Host autorisiert ist, eine IP-Adresse zu verwenden, welche der Host als eigen beansprucht, und zum Verifizieren, dass der Host in der Lage ist, Datenpakete, welche an diese Adresse gesendet werden, zu empfangen, wobei das Verfahren die folgenden Schritte aufweist: – Ausführen des Verfahrens nach einem der Ansprüche 1 bis 11, um zu bestätigen, dass der Host autorisiert ist, die IP-Adresse zu verwenden; – Senden einer Aufgabe bzw. Infragestellung an den Host, der die IP-Adresse als Zieladresse für die Aufgabe bzw. Infragestellung verwendet; – Empfang einer Erwiderung von dem Host; und – Verifizieren, dass die empfangene Erwiderung eine korrekte Erwiderung auf die Aufgabe bzw. Infragestellung ist.
  18. Verfahren gemäß Anspruch 17, wobei die Aufgabe bzw. Infragestellung eine zufällig erzeugte Zahl ist und die Erwiderung die Aufgabe bzw. Infragestellung enthält.
  19. Verfahren gemäß Anspruch 17, wobei die Aufgabe bzw. Infragestellung die mit einer zufällig erzeugten Zahl verknüpfte IP-Adresse aufweist, und wobei die Erwiderung die mit der Aufgabe bzw. Infragestellung verknüpfte IP-Adresse aufweist.
  20. Verfahren gemäß Anspruch 17, wobei die Aufgabe bzw. Infragestellung durch Anwenden einer Ein-Wege-Codier-Funktion an der mit einer zufällig erzeugten Zahl verknüpften IP-Adresse ausgebildet wird, und wobei die Erwiderung durch Anwenden einer Ein-Wege-Codier-Funktion an der mit der Aufgabe bzw. Infragestellung verknüpften IP-Adresse ausgebildet wird.
  21. Verfahren zum Berechtigen eines über ein IP-Netz von einem ersten zu einem zweiten Host übermittelten öffentlichen Schlüssels, wobei das Verfahren die folgenden Verfahrensschritte aufweist: – beim ersten Host: Erzeugen eines Schnittstellen-Identifizierers unter Verwendung des öffentlichen Schlüssels, und Kombinieren des Schnittstellen-Identifizierers mit einem Routing- bzw. Leitwegelenkungs-Vorspann, um eine IP-Adresse für den ersten Host auszubilden; – Senden des öffentlichen Schlüssels von dem ersten zu dem zweiten Knotenpunkt über das IP-Netz; und – beim zweiten Knotenpunkt: Verifizieren, dass der öffentliche Schlüssel der Schlüssel war, der verwendet wurde, um den Schnittstellen-Identifizierer zu erzeugen.
  22. Verfahren zum Anbinden einer IP-Adresse an einen Host, wobei die IP-Adresse einen Routing- bzw. Leitwegelenkungs-Vorspann und einen Schnittstellen-Identifizierer-Teil aufweist, wobei das Verfahren die folgenden Verfahrensschritte aufweist: – Erzeugen des Schnittstellen-Identifizierers durch Kombinieren von einer oder mehreren Komponenten und/oder Ableitungen der Komponenten unter Verwendung einer Codier-Funktion; und – Erzeugen eines Zertifikats, welches mit einem privaten Schlüssel eines öffentlichen-privaten Schlüsselpaares signiert ist, das zu dem Host gehört, wobei das Zertifikat den Schnittstellen-Identifizierer und eine der Komponenten oder der Ableitungen oder weiterer Ableitungen enthält, so dass das Zertifikat unter Verwendung des öffentlichen Schlüssels des Hosts authentisiert werden kann, und der Besitz des Schnittstellen-Identifizierers durch Rekonstruktion des Schnittstellen-Identifizierers unter Verwendung der Inhalte des Zertifikats und durch Vergleich des Ergebnisses gegenüber dem wahren Schnittstellen-Identifizierer verifiziert werden kann.
DE10296445T 2001-03-16 2002-02-15 Adress-Mechanismen im Internet-Protokoll Expired - Lifetime DE10296445B4 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB0106559A GB2367986B (en) 2001-03-16 2001-03-16 Address mechanisms in internet protocol
GB0106559.8 2001-03-16
PCT/SE2002/000276 WO2002076060A2 (en) 2001-03-16 2002-02-15 Address mechanisms in internet protocol

Publications (2)

Publication Number Publication Date
DE10296445T5 DE10296445T5 (de) 2004-04-29
DE10296445B4 true DE10296445B4 (de) 2011-09-29

Family

ID=9910858

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10296445T Expired - Lifetime DE10296445B4 (de) 2001-03-16 2002-02-15 Adress-Mechanismen im Internet-Protokoll

Country Status (6)

Country Link
US (1) US7155500B2 (de)
JP (2) JP4302398B2 (de)
AU (1) AU2002232348A1 (de)
DE (1) DE10296445B4 (de)
GB (1) GB2367986B (de)
WO (1) WO2002076060A2 (de)

Families Citing this family (82)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2367986B (en) * 2001-03-16 2002-10-09 Ericsson Telefon Ab L M Address mechanisms in internet protocol
GB2381423B (en) * 2001-10-26 2004-09-15 Ericsson Telefon Ab L M Addressing mechanisms in mobile IP
US8271686B2 (en) * 2002-02-13 2012-09-18 Intellectual Ventures I Llc Transmission of packet data to a wireless terminal
WO2003094424A1 (en) * 2002-05-03 2003-11-13 Nokia Corporation A method and system in a communication network for allocaring and changing link-level addresses
US7461251B2 (en) * 2002-05-09 2008-12-02 Canon Kabushiki Kaisha Public key certification issuing apparatus
US7352867B2 (en) * 2002-07-10 2008-04-01 General Instrument Corporation Method of preventing unauthorized distribution and use of electronic keys using a key seed
AU2003240171A1 (en) * 2002-07-15 2004-02-02 Nokia Corporation An ipv6 address ownership authentification based on zero-knowledge identification protocols or based on one time password
JP3631225B2 (ja) * 2002-07-25 2005-03-23 キヤノン株式会社 画像処理装置、画像処理装置の制御方法、および画像処理装置の制御プログラム
WO2004025895A1 (en) * 2002-09-13 2004-03-25 Telefonaktiebolaget Lm Ericsson (Publ) Secure broadcast/multicast service
US7756073B2 (en) * 2002-09-20 2010-07-13 Franck Le Method for updating a routing entry
US7508828B2 (en) * 2002-10-18 2009-03-24 Panasonic Corporation Method and device for roaming-connection in global network
EP1420559A1 (de) * 2002-11-13 2004-05-19 Thomson Licensing S.A. Verfahren und Vorrichtung zur Unterstützung eines 6to4 Tunnelprotokols mittels Mechanismus für Netzwerkadressumsetzung
JP4352728B2 (ja) * 2003-03-11 2009-10-28 株式会社日立製作所 サーバ装置、端末制御装置及び端末認証方法
US8261062B2 (en) * 2003-03-27 2012-09-04 Microsoft Corporation Non-cryptographic addressing
US7624264B2 (en) * 2003-03-27 2009-11-24 Microsoft Corporation Using time to determine a hash extension
US7610487B2 (en) 2003-03-27 2009-10-27 Microsoft Corporation Human input security codes
US7793098B2 (en) * 2003-05-20 2010-09-07 Nokia Corporation Providing privacy to nodes using mobile IPv6 with route optimization
JP4054719B2 (ja) * 2003-05-29 2008-03-05 キヤノン株式会社 特定アドレス使用制限装置
US20040268123A1 (en) * 2003-06-27 2004-12-30 Nokia Corporation Security for protocol traversal
US7493652B2 (en) * 2003-08-06 2009-02-17 Microsoft Corporation Verifying location of a mobile node
US7813718B2 (en) 2003-12-24 2010-10-12 Telefonaktiebolaget Lm Ericsson (Publ) Authentication in a communication network
WO2005064973A1 (en) * 2003-12-24 2005-07-14 Telefonaktiebolaget Lm Ericsson (Publ) Authentication in a communication network
KR100610317B1 (ko) 2004-01-06 2006-08-09 삼성전자주식회사 홈 네트워크를 구성하는 기기들에 대한 인증 장치 및 방법
US9686669B2 (en) * 2004-04-08 2017-06-20 Nokia Technologies Oy Method of configuring a mobile node
EP1735990B1 (de) 2004-04-14 2018-05-30 Microsoft Technology Licensing, LLC Authentifizierung und authorisierung für mobile ipv6
US7929689B2 (en) 2004-06-30 2011-04-19 Microsoft Corporation Call signs
KR100626676B1 (ko) * 2004-07-15 2006-09-25 삼성전자주식회사 애드 혹 네트워크에서 프리픽스 할당 방법
KR100636318B1 (ko) * 2004-09-07 2006-10-18 삼성전자주식회사 ＣｏＡ 바인딩 프로토콜을 이용한 어드레스 오너쉽인증방법 및 그 시스템
CN101053210B (zh) 2004-09-15 2010-08-25 诺基亚有限公司 用于进行通信的方法和用于通信的设备
CN101076973B (zh) 2004-09-15 2013-03-27 诺基亚有限公司 在发送重新关联请求之前请求和/或分配新接入点的通信资源
US20060075477A1 (en) * 2004-09-30 2006-04-06 Shenoy Rajesh K Electronic device communication methods, appliance verification methods, appliance programming methods, appliances, articles of manufacture, and client electronic devices
US7424739B2 (en) * 2004-10-29 2008-09-09 Microaoft Corporation On-machine communication verification
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
US20090031130A1 (en) * 2005-04-28 2009-01-29 Matsushita Electric Industrial Co., Ltd. System, associated methods and apparatus for securing prefix-scoped binding updates
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
US20060291422A1 (en) * 2005-06-27 2006-12-28 Nokia Corporation Mobility management in a communication system of at least two communication networks
US7610304B2 (en) * 2005-12-05 2009-10-27 Oracle International Corporation Techniques for performing file operations involving a link at a database management system
JP4791835B2 (ja) * 2006-01-27 2011-10-12 株式会社リコー ネットワーク機器
GB0601913D0 (en) 2006-01-31 2006-03-08 Ericsson Telefon Ab L M Packet re-direction in a communication network
US7653813B2 (en) * 2006-02-08 2010-01-26 Motorola, Inc. Method and apparatus for address creation and validation
US8601160B1 (en) * 2006-02-09 2013-12-03 Mcafee, Inc. System, method and computer program product for gathering information relating to electronic content utilizing a DNS server
KR100773822B1 (ko) * 2006-03-20 2007-11-06 주식회사 케이티프리텔 효율적인 ＩＰｖ６용 ＩＰ 주소 할당을 위한 전화 접속네트워킹 방법
US8086842B2 (en) 2006-04-21 2011-12-27 Microsoft Corporation Peer-to-peer contact exchange
US8161185B2 (en) * 2006-04-24 2012-04-17 Cisco Technology, Inc. Method and apparatus for assigning IPv6 link state identifiers
US8467301B2 (en) * 2006-06-05 2013-06-18 Hewlett-Packard Development Company, L.P. Router misconfiguration diagnosis
JP2010502036A (ja) * 2006-08-25 2010-01-21 パナソニック株式会社 複数のアドレスを登録する際にアドレスを検証するための方法及び装置
US8254311B2 (en) * 2006-10-30 2012-08-28 Panasonic Corporation Binding update method, mobile terminal, home agent, and binding update system
KR100789773B1 (ko) * 2006-12-08 2007-12-28 한국전자통신연구원 다중 홉 무선 근거리통신망에서 메쉬 네트워킹 자동 설정방법과, 가상 링크 설정 방법과, 패킷 전송 방법 및 이를위한 무선 단말기
WO2008113405A1 (en) * 2007-03-16 2008-09-25 Telefonaktiebolaget Lm Ericsson (Publ) Securing ip traffic
JP4872130B2 (ja) * 2007-03-29 2012-02-08 日本電気株式会社 通信システム、情報隠蔽アドレス利用方法、及びプログラム
US8045558B2 (en) * 2007-04-23 2011-10-25 Cisco Technology, Inc. Extensions to IPv6 neighbor discovery protocol for automated prefix delegation
US8266427B2 (en) * 2007-06-08 2012-09-11 Cisco Technology, Inc. Secure mobile IPv6 registration
CA2693312A1 (en) * 2007-06-22 2008-12-31 Telefonaktiebolaget L M Ericsson (Publ) System and method for access network multi-homing
US8266062B2 (en) * 2007-06-27 2012-09-11 Microsoft Corporation Server side reversible hash for telephone-based licensing mechanism
CN102739677B (zh) 2007-06-29 2015-09-09 华为技术有限公司 一种加密生成地址的配置方法、系统和装置
GB2454897A (en) * 2007-11-22 2009-05-27 Ericsson Telefon Ab L M Cryptographically generated IP addresses
RU2469492C2 (ru) * 2008-03-04 2012-12-10 Телефонактиеболагет Лм Эрикссон (Пабл) Делегирование ip адреса
EP2272202B1 (de) * 2008-04-14 2020-06-10 Philips Intellectual Property & Standards GmbH Verfahren zur verteilten identifikation und eine station in einem netzwerk
CN101594230B (zh) 2008-05-30 2012-06-27 华为技术有限公司 处理动态主机配置消息的方法、装置及系统
CN101621785B (zh) * 2008-07-04 2013-03-27 华为技术有限公司 移动节点的注册、通信、切换方法及装置
US8699378B2 (en) * 2009-09-30 2014-04-15 At&T Intellectual Property I, L.P. Methods and apparatus for discovering hosts on an IPv6 network
EP2369808A1 (de) 2010-03-22 2011-09-28 Thomson Telecom Belgium Verfahren für sicheren Zugriff auf Daten oder einen Dienst über eine das Verfahren implementierende Vorrichtung und zugehörige Vorrichtung
EP2381651A1 (de) * 2010-04-22 2011-10-26 Gemalto SA Verfahren zur Erzeugung einer Internetprotokolladresse
US8560648B2 (en) * 2010-11-10 2013-10-15 Microsoft Corporation Location control service
EP2697956B1 (de) * 2011-04-15 2019-10-30 Unify GmbH & Co. KG Verfahren zum genieren von adressen in einem computernetzwerk
WO2013006918A1 (en) * 2011-07-14 2013-01-17 Commonwealth Scientific And Industrial Research Organisation Cryptographic processes
EP2549709A1 (de) * 2011-07-21 2013-01-23 British Telecommunications Public Limited Company Adressenzuweisungssystem
US9319307B2 (en) * 2013-09-06 2016-04-19 At&T Intellectual Property I, L.P. Providing differentiated service to traffic flows obscured by content distribution systems
JP6348019B2 (ja) * 2014-08-28 2018-06-27 ルネサスエレクトロニクス株式会社 通信システム、通信装置、自動車および通信方法
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
US10097525B2 (en) * 2016-03-08 2018-10-09 Qualcomm Incorporated System, apparatus and method for generating dynamic IPV6 addresses for secure authentication
US10248365B2 (en) * 2016-12-30 2019-04-02 Konica Minolta Laboratory U.S.A., Inc. Method and system of using OAuth2 to secure neighbor discovery
US10447665B2 (en) * 2017-03-31 2019-10-15 Konica Minolta Laboratory U.S.A., Inc. IPv6 link local secure network with biometric security to secure IOT devices
WO2018235085A1 (en) * 2017-06-21 2018-12-27 Yissum Research Development Company Of The Hebrew University Of Jerusalem Ltd. METHOD OF CERTIFYING ADDRESS PROPERTIES AND ASSOCIATED SYSTEM
JP7385285B2 (ja) * 2018-11-14 2023-11-22 コネクトフリー株式会社 情報処理方法、情報処理プログラム、情報処理装置及び情報処理システム
US11096047B2 (en) * 2018-11-27 2021-08-17 LGS Innovations LLC Methods and systems for SCTP probing
US11381560B2 (en) * 2019-08-05 2022-07-05 Visa International Service Association Embedding credentials in network addresses
US20210377296A1 (en) * 2020-05-29 2021-12-02 Avaya Management L.P. Method and system for discovering, reporting, and preventing duplicate address detection attacks
US11165748B1 (en) * 2020-10-13 2021-11-02 Cisco Technology, Inc. Network security from host and network impersonation
CN114422474B (zh) * 2021-12-20 2023-11-10 广西壮族自治区公众信息产业有限公司 基于RADIUS服务器的用户IPv6地址生成方法

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2172127B (en) * 1985-03-06 1988-10-12 Ferranti Plc Data compression system
US5032987A (en) * 1988-08-04 1991-07-16 Digital Equipment Corporation System with a plurality of hash tables each using different adaptive hashing functions
US5351295A (en) * 1993-07-01 1994-09-27 Digital Equipment Corporation Secure method of neighbor discovery over a multiaccess medium
US5651069A (en) * 1994-12-08 1997-07-22 International Business Machines Corporation Software-efficient message authentication
US5872917A (en) * 1995-06-07 1999-02-16 America Online, Inc. Authentication using random challenges
US5856267A (en) * 1995-06-07 1999-01-05 American Trim, Llc Transfer printing metal substrates
JPH09252323A (ja) * 1996-01-11 1997-09-22 Sony Corp 通信システムおよび通信装置
US5684951A (en) * 1996-03-20 1997-11-04 Synopsys, Inc. Method and system for user authorization over a multi-user computer system
GB9610154D0 (en) * 1996-05-15 1996-07-24 Certicom Corp Tool kit protocol
US5958053A (en) * 1997-01-30 1999-09-28 At&T Corp. Communications protocol with improved security
US6101499A (en) * 1998-04-08 2000-08-08 Microsoft Corporation Method and computer program product for automatically generating an internet protocol (IP) address
FI105965B (fi) * 1998-07-07 2000-10-31 Nokia Networks Oy Autentikointi tietoliikenneverkosssa
US6859791B1 (en) * 1998-08-13 2005-02-22 International Business Machines Corporation Method for determining internet users geographic region
JP2000092236A (ja) * 1998-09-11 2000-03-31 Ntt Mobil Communication Network Inc 情報提供システム
FI106417B (fi) * 1998-12-08 2001-01-31 Nokia Mobile Phones Ltd Menetelmä tiedonsiirron optimoimiseksi
US6542508B1 (en) * 1998-12-17 2003-04-01 Watchguard Technologies, Inc. Policy engine using stream classifier and policy binding database to associate data packet with appropriate action processor for processing without involvement of a host processor
GB2348569B (en) * 1999-03-31 2003-11-05 Ericsson Telefon Ab L M IP Address allocation for mobile terminals
JP2001160823A (ja) * 1999-12-02 2001-06-12 Hitachi Cable Ltd モデム共有装置
JP2001160828A (ja) * 1999-12-03 2001-06-12 Matsushita Electric Ind Co Ltd セキュリティ・ゲートウェイ装置におけるｖｐｎ通信方法
US6904456B2 (en) * 2001-02-20 2005-06-07 Microsoft Corporation Lock-free cache management
GB2367986B (en) * 2001-03-16 2002-10-09 Ericsson Telefon Ab L M Address mechanisms in internet protocol

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
NARTENT T., DRAVES R.: RFC 3041: Privacy Extensions for Stateless Address Autoconfiguration in IPv6, 31.01.2001, (URL: http://www.watersprings.org/pub/rfc/rfc3041.txt) (recherchiert am 26.04.10) *

Also Published As

Publication number Publication date
JP4944845B2 (ja) 2012-06-06
US20020133607A1 (en) 2002-09-19
JP4302398B2 (ja) 2009-07-22
US7155500B2 (en) 2006-12-26
WO2002076060A3 (en) 2003-01-23
GB2367986B (en) 2002-10-09
JP2004533741A (ja) 2004-11-04
JP2008271601A (ja) 2008-11-06
AU2002232348A1 (en) 2002-10-03
DE10296445T5 (de) 2004-04-29
GB2367986A (en) 2002-04-17
GB0106559D0 (en) 2001-05-02
WO2002076060A2 (en) 2002-09-26

Similar Documents

Publication Publication Date Title
DE10296445B4 (de) Adress-Mechanismen im Internet-Protokoll
DE69831974T2 (de) Verfahren zur paketauthentifizierung in gegenwart von netzwerkadressübersetzungen und protokollumwandlungen
DE102014224694B4 (de) Netzwerkgerät und Netzwerksystem
DE60309367T2 (de) Netz-System unter Verwendung eines Namensservers mit einer Funktion zur Erzeugung von Pseudo-Hostnamen und Pseudo-IP-Adressen
DE602004007301T2 (de) Adressierungs-verfahren und -vorrichtung zum aufbau von hip-verbindungen zwischen gewöhnlichen und hip-fähigen netzknoten
DE112005002651B4 (de) Verfahren und Vorrichtung zur Authentifikation von mobilen Vorrichtungen
DE102011011652B4 (de) Verfahren zum Verwenden eines ECDSA mit Winternitzeinmalsignatur
DE60308251T2 (de) Vorrichtung zur Bereitstellung von öffentlichen Schlüsselzertifikaten
EP2055072B1 (de) Verfahren und Anordnung zum Bereitstellen eines drahtlosen Mesh-Netzwerks
CN100592746C (zh) 移动因特网协议中的寻址机制
DE60302882T2 (de) Sicherheitsübertragungsprotokoll für ein mobilitäts-ip-netzwerk
EP0872076B1 (de) Verfahren zum rechnergestützten austausch kryptographischer schlüssel zwischen einer ersten computereinheit und einer zweiten computereinheit
DE60201522T2 (de) Ermöglichen legales abfangen von ip-verbindungen
DE112019001209T5 (de) Sicheres Ble-Just-Works-Koppelverfahren gegen Man-In-The-Middle-Angriffe
US20070242638A1 (en) Fast Network Attachment
US20180115520A1 (en) Dark virtual private networks and secure services
EP1080557A2 (de) Verfahren und anordnung zum rechnergestützten austausch kryptographischer schlüssel zwischen einer ersten computereinheit und einer zweiten computereinheit
DE102006006072B3 (de) Verfahren zum Sichern der Authentizität von Nachrichten, die gemäß einem Mobile Internet Protokoll ausgetauscht werden
WO2008074621A1 (de) Verfahren und server zum bereitstellen einer geschützten datenverbindung
EP1468520B1 (de) Verfahren zur datenverkehrssicherung in einer mobilen netzumgebung
DE102004047692A1 (de) Kommunikationssystem und Verfahren zur Bereitstellung eines mobilen Kommunikationsdienstes
DE19518546C1 (de) Verfahren zum rechnergestützten Austausch kryptographischer Schlüssel zwischen einer Benutzercomputereinheit U und einer Netzcomputereinheit N
DE19518544C1 (de) Verfahren zum rechnergestützten Austausch kryptographischer Schlüssel zwischen einer Benutzercomputereinheit und einer Netzcomputereinheit
DE102007003492B4 (de) Verfahren und Anordnung zum Bereitstellen eines drahtlosen Mesh-Netzwerks
DE102015013949A1 (de) Eine Soft- u. Hardwarekombination genannt &#34;Dome-Ware&#34; für den verschlüsselten und gegen Manipulationen gesicherten Datenaustausch zwischen mindestens zwei prozessorgesteuerten Endgeräten, geeignet um &#34;Man-In-The-Middle&#34;-Angriffe zu erkennen und abzuwehre

Legal Events

Date Code Title Description
8110 Request for examination paragraph 44
R018 Grant decision by examination section/examining division
R020 Patent grant now final

Effective date: 20111230

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0029000000

Ipc: H04L0069000000

R071 Expiry of right