Zusammenfassung

  • RFC 3012 ließ den Mobile-IPv4-Foreign-Agent eine eigene frische Challenge ausgeben und fehlende, bereits verwendete oder unbekannte Werte erkennen, bevor die entfernte AAA-Prüfung abgeschlossen war.
  • Der passende Wert belegte nur lokale Frische; Authentifizierung, Autorisierung, angenommene Registrierung, Forwarding-Zustand und tatsächlich transportierter Verkehr blieben eigene Nachweise.

Roaming verteilte Wissen auf verschiedene Orte. Das mobile Gerät stand vor dem besuchten Netz, während seine prüfbaren Zugangsdaten im Heimatbereich lagen. Der Foreign Agent sollte eine Registration Request behandeln, ohne mit jedem denkbaren Besucher vorab eine Security Association zu besitzen.

Eine entfernte Prüfung allein ließ ein Zeitfenster offen. Alte Registrierungen konnten erneut eintreffen, während Authentication, Authorization and Accounting noch arbeitete. Die besuchte Kante brauchte deshalb einen Zustand, den sie selbst erzeugt hatte.

RFC 3012, im November 2000 veröffentlicht, definierte eine Challenge extension in Agent Advertisements. Ihr Zufallswert sollte mindestens 32 Bit lang sein. Das mobile Gerät kopierte ihn in eine MN-FA Challenge extension der Registration Request.

Entscheidend war nicht bloß Zufälligkeit, sondern Herkunft. Der Foreign Agent wusste, welche Werte er zuletzt auf diesem Link ausgegeben hatte. Er konnte daher lokale Frische prüfen, obwohl die Identitätsentscheidung noch außerhalb lag. Eine Antwort auf die eigene Challenge war kein Ausweis.

Die Spezifikation machte das durch die Reihenfolge deutlich. Auf MN-FA Challenge musste Mobile-Foreign Authentication oder MN-AAA Authentication folgen. Eine Registrierung mit Challenge, aber ohne eine der beiden Authentifizierungen, war stillschweigend zu verwerfen.

Bei direkter Security Association band Mobile-Foreign Authentication die Anfrage. Sonst musste der Knoten MN-AAA verwenden und sollte den Network Access Identifier aus RFC 2794 mitsenden. Dessen Realm half, die Prüfung in die richtige administrative Domäne zu leiten; der Name bewies nicht seinen Besitzer.

Damit entstanden getrennte Aussagen. Die Challenge verwies auf jüngsten lokalen Zustand. Der Authenticator band Daten an Schlüssel und Algorithmus des SPI. Die AAA-Infrastruktur prüfte Credentials. Die Policy entschied über Zulassung. Keine Aussage ersetzte die folgende.

Drei Fehlercodes erhielten diese Unterschiede. MISSING_CHALLENGE bezeichnete das fehlende Pflichtfeld. STALE_CHALLENGE bezeichnete einen bereits von diesem Knoten verwendeten Wert. UNKNOWN_CHALLENGE bedeutete, dass der Wert weder der letzte erfolgreich zurückgegebene noch Teil der jüngsten CHALLENGE_WINDOW-Anzeigen war. Das IANA-Register führt die Zuweisungen fort.

Alle drei als „Authentifizierung fehlgeschlagen“ zu zählen, vernichtet Ursache. Fehlende Struktur, historische Wiederverwendung und nicht nachvollziehbare Ausgabe sind verschiedene Betriebszustände. RFC 3012 machte den Ort des Scheiterns sichtbar.

Für Paketverlust brauchte es eine schmale Ausnahme. Kam dieselbe Request mit gleicher 64-Bit-Identification und gleicher Challenge erneut, während der passende Datensatz noch pending war, durfte der Foreign Agent sie wieder weiterleiten. Außerhalb dieser lebenden Transaktion war Wiederverwendung normalerweise stale.

Replay-Schutz bestand somit aus Gedächtnis. Agent, Knoten, Wert, Identification, Pending-Zustand und Ablaufzeit mussten zusammenbleiben. Jede Dublette abzulehnen hätte normale Retransmissionen gebrochen; jeden jüngeren Wert zu dulden hätte die Schutzgrenze aufgelöst.

Auch die Antwort des Home Agent brauchte Bindung. Blieb die Challenge in der weitergeleiteten Anfrage, sollte der Foreign Agent sie im Pending-Datensatz halten und eine Registration Reply ohne denselben Wert ablehnen. Der Gleichlauf belegte Transaktionszugehörigkeit, nicht eingerichtete Route oder Anwendungszustellung.

Konnte der Agent die Challenge über eine direkte MN-FA-Beziehung prüfen und vor dem Weiterleiten entfernen, sollte er stattdessen die Identification lokal speichern. Das Format auf dem nächsten Abschnitt änderte sich; die Beweispflicht blieb.

Die eigentliche Verifikation lag bewusst außerhalb von Mobile IPv4. Der Anhang nannte sie „verification infrastructure“. Der Foreign Agent konnte Authentifizierungsmaterial übergeben und auf ein geschütztes Ergebnis warten. Protokoll, Betreiber und interne Policy dieser Infrastruktur blieben offen.

Das war eine dünne gemeinsame Schicht. Der Standard beschrieb Übergabe, Reihenfolge und lokale Prüfungen, ohne ein AAA-Produkt oder eine Verwaltungsordnung vorzuschreiben. Austauschbarkeit blieb möglich, sofern die Bedeutung an der Schnittstelle erhalten blieb.

Für damalige Systeme reservierte CHAP_SPI 2 eine CHAP-artige MD5-Berechnung in Nähe zu RADIUS. Die Sicherheitsbetrachtung sagte zugleich, sie sei schwächer als HMAC-MD5 und nach Möglichkeit zu vermeiden. Installierte Kompatibilität war kein zeitloses Sicherheitsurteil.

Auch Denial of Service blieb möglich. Ein Angreifer konnte Anfragen wiederholen und eine wie Ablehnung wirkende Reply auslösen, während eine legitime Annahme noch unterwegs war. Die erste eintreffende Nachricht konnte das Verhalten des mobilen Geräts bestimmen. Lokale Frische ordnete keinen verteilten Gesamtablauf.

Bei Challenges unter vier Byte sollte zusätzlich die Identification aufbewahrt werden. Ein kurzer Wert gewann keine Entropie dadurch, dass man ihn Zufallswert nannte. Historie und Transaktionskennung mussten die Lücke begrenzt ausgleichen.

RFC 4721 ersetzte RFC 3012 im Jahr 2007. Der Foreign Agent musste nun anwendbare Challenges je mobilem Knoten erfassen; Werte, die vor dem zuletzt verwendeten angekündigt worden waren, durften nicht wieder genutzt werden. Die Revision klärte Anzeigen und Replies, schützte stärker gegen falsche Nachrichten und ergänzte HMAC-MD5.

Das beweist keinen bestimmten Angriff. Es belegt aber, dass Frische eine geordnete Geschichte ist: Aussteller, Knoten, letzter akzeptierter Wert, laufende Anfrage und abdeckender Authenticator. Zufällige Bytes außerhalb dieser Beziehungen haben keine eigenständige Autorität.

Die Geschichte unterscheidet sich von RFC 2002. Dort ging es um den zeitlich begrenzten Binding-Zustand zwischen Home Address und Care-of Address. RFC 3012 behandelte den vorgelagerten Schritt am besuchten Rand, bevor der Home Agent den Binding akzeptierte.

Sie ist auch nicht bloß PPP CHAP in anderer Verpackung. CHAP authentifizierte einen Peer in einem PPP-Link. Hier speiste ein Foreign Agent lokale Frische in eine Mobile-IPv4-Registrierung ein und konnte eine getrennte AAA-Infrastruktur hinzuziehen. Ähnliche Berechnung bedeutete nicht gleiche Kontrollfläche.

Lu Hengs Prinzip einer minimalen Anfangsspezifikation passt zu dieser Architektur: gemeinsam wurden Format, Reihenfolge, Fenster, Fehler und Korrelation. Verifikator und Zulassung blieben lokal wählbar. Running-Code Primacy verhindert wiederum, aus der veröffentlichten Regel auf eine konkrete Implementierung zu schließen.

Ein Mitschnitt kann die zurückgesandte Challenge zeigen. Ein Kryptolog beweist die Prüfung. Ein Policy-Log beweist Zulassung. Der Home Agent beweist den angenommenen Binding. Datenverkehr beweist Nutzung. Das Etikett „Challenge/Response“ darf diese Belege nicht zusammenfalten.

Das Gateway stellte eine Challenge, weil es genau diesen Sachverhalt selbst kontrollieren konnte. Vertrauen musste erst noch aus anderen Systemen kommen. Darin lag die präziseste Aussage von RFC 3012.

Sources