Zusammenfassung

  • RFC 5269 trennt das CGA/SEND-Paar für den Anspruch auf die Quelladresse, ein eigenständiges Paar zum geschützten Transport des Geheimnisses und den gemeinsamen Handover-Schlüssel für den MAC des FBU.
  • Ein erfolgreicher MAC ermächtigt den previous access router zu einer Forwarding-Änderung für genau eine previous care-of CGA. Er bestätigt weder Attachment und NCoA noch Zustellung, Nutzer, Anwendung oder eine spätere Mobile-IPv6-Bindung.

Die gefährliche Handlung ist eine konkrete Umleitung

Ein Fast Binding Update kann den bisherigen Zugangsrouter anweisen, Verkehr für die alte Adresse eines mobilen Knotens umzulenken. Könnte jeder nahe Sender diese Nachricht erzeugen, ließe sich der Datenstrom eines Opfers abfangen, ohne dessen Nutzdatenverschlüsselung zu brechen.

RFC 5269 bereitet deshalb vor dem Wechsel einen shared handover key vor. Der mobile Knoten berechnet damit einen Authorization MAC für das FBU. Der PAR sucht den zur alten Care-of-CGA gehörenden Eintrag und ändert das Forwarding erst nach erfolgreicher Prüfung. Ohne passenden Schlüssel darf er die Anweisung nicht ausführen.

Diese Kontrolle ist stark, weil das autorisierte Objekt eng definiert ist. Der MAC beobachtet keine Funkassoziation, führt kein DAD für die NCoA aus und sieht weder eine Pufferfreigabe am neuen Router noch den Empfang in einer Anwendung. Aus „Forwarding-Änderung autorisiert“ darf daher nicht „Handover authentifiziert“ werden.

Drei Schlüssel halten drei Aussagen auseinander

Das erste Schlüsselpaar gehört zu CGA und SEND. Die RtSolPr wird von der Care-of-CGA des mobilen Knotens versandt und enthält CGA-Parameter sowie eine SEND-Signatur. Eine erfolgreiche Prüfung zeigt dem Router, dass der Absender diese Quell-CGA in diesem Vorgang beanspruchen darf.

Das zweite Paar wird nur für die Verschlüsselung des Handover-Schlüssels erzeugt. Algorithmus und öffentliche Parameter entsprechen SEND, die Schlüssel müssen jedoch unabhängig sein. RFC 5269 untersagt ihre Nutzung für andere Verschlüsselung oder Signaturen. Der öffentliche Teil steht in der Handover Key Request Option; der private Teil bleibt beim mobilen Knoten und entschlüsselt die Antwort.

Das dritte Objekt ist das vom Access Router erzeugte oder wiedergefundene gemeinsame Geheimnis. Der Router verschlüsselt es für den dedizierten öffentlichen Schlüssel, liefert es in der Handover Key Reply Option und verwendet es später zur FBU-Authentisierung.

Wer diese Rollen als ein Feld mobilityKey speichert, verliert das Sicherheitsmodell. Der SEND-Schlüssel signiert einen Adressanspruch, der Transport-Schlüssel öffnet ein Geheimnis, der gemeinsame Schlüssel autorisiert eine Nachrichtenklasse. Erzeuger, erlaubte Operation, Rotation und Folgen einer Offenlegung sind verschieden.

Zustandsaufbau beginnt erst nach der SEND-Prüfung

Die RtSolPr enthält den Transport-Public-Key, den bevorzugten FBU Algorithm Type, CGA- und Signature-Optionen sowie einen SEND-Nonce. Der Access Router muss SEND zuerst validieren. Bei einem Fehler sendet er keine Handover Key Reply, legt keinen Schlüssel an und verändert auch keinen bereits vorhandenen gültigen Datensatz für die Adresse.

Die Reihenfolge begrenzt Ressourcenmissbrauch. Zufallsmaterial zu erzeugen, zu verschlüsseln und im Cache zu halten kostet Speicher und Rechenzeit. Vor der Prüfung des Urhebers darf dieser Zustand nicht entstehen. Ratenbegrenzung und Grenzen für offene Zustände bleiben auch bei signierten Anfragen nötig, denn Authentisierung schafft keine unbegrenzte Kapazität.

Im Audit sind deshalb zwei Ergebnisse erforderlich: SEND-Validierung und Zulassungsentscheidung. „Signatur gültig“ sagt nicht, ob eine Anfrage innerhalb der Kapazitätsregeln angenommen wurde. „Schlüssel geliefert“ sagt nicht, ob die Prüfung tatsächlich vor der Allokation lag.

Entschlüsselung allein beglaubigt den antwortenden Router nicht

Nach einer gültigen Anfrage gibt der Router entweder den bereits mit der CGA verbundenen Schlüssel zurück oder erzeugt einen neuen. Die PrRtAdv enthält das verschlüsselte Geheimnis, HK-LIFETIME, den gewählten Algorithm Type und den empfangenen Nonce.

Auch die Routerseite benötigt eine überprüfbare Identität. Der Access Router verfügt über ein für SEND geeignetes Zertifikat, unterstützt dessen Auffindung und signiert die Antwort mit dem zertifizierten Schlüssel. Ist der Zertifizierungspfad nicht im Cache, dienen CPS/CPA-Nachrichten zur Beschaffung. Der mobile Knoten prüft Pfad, Trust Anchor und Signatur und verwirft eine Antwort ohne beglaubigten Router-Key.

Der Nonce bindet die Antwort an genau die Anfrage, die den Transport-Key lieferte. Bei parallelen Vorgängen wählt er das passende private Schlüsselpaar. Gibt es keine Zuordnung, wird die Nachricht verworfen; das Gerät probiert nicht wahllos alle lokalen Private Keys.

Eine belastbare Quittung umfasst daher Anfragegeneration, CGA-Anspruch, SEND-Signatur, Routerentscheidung, Zertifizierungspfad, PrRtAdv-Signatur, Nonce-Echo, Algorithmuswahl, zugehörigen privaten Schlüssel und Lebensdauer. „Entschlüsselung erfolgreich“ ist nur ein Teil davon.

Ein Cache-Schlüssel beschreibt eine Beziehung

Der Router indiziert das Geheimnis über die CGA des mobilen Knotens und hält Algorithmus und Ablaufzeit daneben. Der mobile Knoten wählt später nach der Identität des previous access router und nach der previous care-of CGA, die er auf dessen Link genutzt hatte. Das Home Address Option des FBU trägt diese alte CGA zum PAR zurück.

Ein Gerät kann Material mehrerer Router halten oder rasch zu einem Link zurückkehren. Ein Router bedient viele Geräte. Die Bytes des Geheimnisses bezeichnen daher die Autorität nicht allein. Router, mobile Adresse, Generation, Algorithmus, Gültigkeit und Zweck bilden gemeinsam die Beziehung.

Ein Cache nur nach Gerätekennung oder aktuellem Router kann eine kryptografisch brauchbare, aber sachlich falsche Verknüpfung auswählen. Ein korrekter MAC korrigiert keinen fehlerhaften Datenbank-Join.

Die Algorithmuswahl gehört zur Beweiskette

Der mobile Knoten nennt seinen bevorzugten FBU-Authentisierungsalgorithmus. Unterstützt der Router ihn, soll er denselben Wert zurückgeben. Andernfalls muss die Alternative gleich stark oder stärker sein. Für den Authenticator zählt der tatsächlich zurückgegebene Algorithm Type.

Mehrere Routerantworten dürfen mehrere Schlüssel erzeugen. Falls keine angebotene Methode unterstützt wird, kann der Knoten erneut anfragen. Er sollte aber nicht auf den Bidding-down-Druck eines kompromittierten Routers reagieren, indem er unter seine ursprüngliche Präferenz fällt.

MAC valid reicht als Protokollzeile nicht. Angeforderter Wert, Antwort, Policy-Generation und ausgeführte Implementierung müssen den Befund begleiten. Eine spätere Regeländerung darf die Bedeutung alter Prüfungen nicht rückwirkend verändern.

Im Cache und noch gültig heißt nicht erneut erteilt

Für das dedizierte Transportpaar empfiehlt RFC 5269 höchstens zwölf Stunden oder zehn Handovers, je nachdem, was zuerst erreicht wird. Der gemeinsame Handover-Schlüssel hat standardmäßig zwölf Stunden beziehungsweise 43.200 Sekunden Lebensdauer.

Der Router erzeugt ausreichend starkes Zufallsmaterial und einen eindeutigen Wert pro CGA Public Key. Handover-Schlüssel sollen untereinander und gegenüber CGA-Schlüsseln unkorreliert sein.

Der PAR darf einen noch gültigen Schlüssel behalten, weil der mobile Knoten erneut wechseln kann, bevor die normale Mobile-IPv6-Bindung abgeschlossen ist. Kehrt der Knoten mit derselben Care-of-CGA zurück, darf der Router denselben Schlüssel nochmals senden. Der Knoten darf aber nicht aus seiner lokalen Kopie auf eine fortbestehende Ermächtigung schließen. Er muss den Schlüssel erneut empfangen.

Lokaler Besitz, laufender Timer, Speicherung beim Router und erneute Ausgabe sind vier verschiedene Zustände. Nach Abschluss der normalen Bindung sollte der Knoten das Geheimnis löschen; der PAR löscht es nach Forwarding-Timeout oder Ablauf von HK-LIFETIME.

Ein zweckgebundener Schlüssel ist kein universeller Identitätsnachweis

Das gemeinsame Geheimnis verschlüsselt keine Nutzdaten. Es ist kein Application Session Key, kein Abonnentennachweis und keine Mitarbeiteridentität. Es prüft die geplante NCoA nicht, ersetzt weder Binding Update noch Return Routability und belegt keine Annahme durch Home Agent oder Correspondent Node.

RFC 5568 ist die heutige FMIPv6-Basis und hat RFC 5268 abgelöst. Das Dokument verweist weiterhin auf RFC 5269 für die Erzeugung des Schlüssels, der den FBU Authenticator schützt. Die Erweiterung muss deshalb mit dem aktuellen Paketformat gelesen werden; ein veraltetes Format wäre ein eigener Implementierungsfehler.

Spätere SEND-Arbeiten können Zertifikate und Trust-Anchor-Verteilung verbessern. Damit wird die Aussage über den Unterzeichner stärker, nicht der Bedeutungsumfang des MAC größer. Hohe Sicherheit ändert nicht das Prädikat.

Laufender Code zeigt die einzelnen Glieder

Lu Hengs Running-Code Primacy richtet den Blick auf die ausgeführten Schritte: CGA-Anspruch, SEND-Prüfung, dedizierter Transport-Key, signierte Antwort eines zertifizierten Routers, passender Nonce, Cache-Beziehung, Algorithmus, FBU-Authenticator und Forwarding-Entscheidung.

Die Trennung der reality layers hält Besitz, Autorisierung und Ergebnis auseinander. Ein Private Key belegt Kontrolle über eine Kryptooperation. SEND bestätigt den begrenzten Adressanspruch. Das Zertifikat ordnet die Routerantwort ein. Der Nonce korreliert Nachrichten. Der MAC ermächtigt die Umleitung. Keiner dieser Befunde misst den tatsächlichen Anschluss oder die Dienstkontinuität.

Eine Abstraktion bleibt reversibel, wenn jeder grüne Status zu Schlüsselzweck, Subjektbeziehung, Generation, Algorithmus, Zeitgrenze und Nachricht zurückführt. Endet die Spur bei „authentifiziert“, wurde die wichtigste Grenze der Kryptografie entfernt.

Quellen