Zusammenfassung

  • RFC 5419 dokumentiert die damalige Begründung, Binding Updates in Mobile IPv6 über das Heimat-AAA zu authentifizieren; sein Beispiel macht die Schlüsselübergabe an den Home Agent jedoch nicht zu einem allgemeinen IETF-Vertrag.
  • Der Text trennt einen veranschaulichten RADIUS-Ablauf von einem standardisierten Verfahren, aus der MN–AAA-Assoziation einen MN–HA-Schlüssel samt Sicherheitsassoziation zu erzeugen.
  • RFC 4877 brachte später einen IKEv2/IPsec-Pfad und entkräftete einige ältere Argumente. Die Begründung aus dem Jahr 2009 belegt nicht, was heute eingesetzt wird.

Eine Binding Update enthält noch keine vollständige Vertrauenskette

Mobile IPv6 ermöglicht einem Gerät, seine Heimatadresse auch außerhalb des Heimatnetzes beizubehalten. Der mobile Knoten (MN) sendet ein Binding Update (BU) an seinen Home Agent (HA), um die aktuelle Care-of-Adresse mitzuteilen. Der HA speichert die Bindung und kann Pakete durch einen Tunnel zum mobilen Knoten leiten. Im Grundmodell schützt eine IPsec-Sicherheitsassoziation die Signalisierung zwischen MN und HA. Die Kommunikationspartner sind klar. Offen bleibt die Betriebsfrage: Wie erhalten beide passende Schlüssel, wenn die Instanz für Teilnehmerkonten in einem anderen System sitzt?

RFC 5419 erschien im Januar 2009 als Informational-Dokument, um die Beweggründe für die Authentifizierungsoption aus RFC 4285 zu bewahren. Es betont, dass die Alternative IPsec nicht ablöst. Die Beispiele beziehen sich auf CDMA2000- und WiMAX-Architekturen, wie die Autoren sie damals beschrieben. Betreiber wollten das Heimat-AAA weiterverwenden, Teilnehmerprofile nutzen und Heimatadresse oder HA dynamisch zuweisen. Das sind historische Anforderungen, die im Dokument festgehalten wurden, keine Messwerte heutiger Netze. (RFC 5419, Abschnitte 1 und 5)

RFC 4285 definiert zwei relevante Optionen. Die MN–AAA-Option authentifiziert ein BU anhand der gemeinsamen Mobilitäts-Sicherheitsassoziation zwischen MN und Heimat-AAA. Die Rückmeldung des HA, das Binding Acknowledgement, muss dagegen die MN–HA-Option verwenden. RFC 4285 sagt, dass der HA die Authentifizierung einer externen Heimat-AAA-Stelle über einen authentifizierten Kanal nutzt; die genaue Kommunikation zwischen HA und AAA liegt außerhalb seines Umfangs. Die Authentifizierung der Anfrage und der Schlüsselzustand für die Antwort hängen zusammen, sind aber nicht identisch. (RFC 4285, Abschnitt 5.2)

Was das RADIUS-Beispiel zeigt

Im CDMA2000-Beispiel von RFC 5419 leitet der HA die Authentifizierungsdaten an einen RADIUS-Server weiter. AAA prüft das BU, berechnet aus dem MN–AAA-Geheimnis und einem Zeitstempel einen Sitzungsschlüssel und übermittelt ihn in einem Access-Accept mit einem von 3GPP2 definierten herstellerspezifischen Attribut an den HA. Dieser ordnet den Schlüssel einer MN–HA-Sicherheitsassoziation zu; das Beispiel verwendet SPI 5. Mit dieser SA authentifiziert der HA das Binding Acknowledgement. Der mobile Knoten berechnet denselben Schlüssel, prüft damit die Antwort und kann ihn für spätere BUs verwenden. (RFC 5419, Abschnitt 6.2)

Der Ablauf macht eine Kontrollgrenze sichtbar. Die Teilnehmerauthentifizierung beginnt mit einem zwischen MN und AAA geteilten Geheimnis. Für die weitere HA-Signalisierung ist ein Schlüssel erforderlich, den MN und HA verwenden können. Das Beispiel erklärt, wie ein bestimmtes Netzprofil Sitzungsmaterial zwischen diesen Rollen überträgt. Das genannte RADIUS-Attribut stammt jedoch aus der 3GPP2-Definition; RFC 4285 macht daraus kein universelles Attribut.

Anschließend benennt RFC 5419 die Lücke ausdrücklich: RFC 4285 legt nicht fest, wie aus der MN–AAA-Assoziation der gemeinsame MN–HA-Schlüssel und die zugehörige SA entstehen. Stattdessen braucht es netzspezifische, nicht vom IETF standardisierte Verfahren. Als Gegenbeispiel nennt RFC 5419 RFC 3957, das für Mobile IPv4 eine Schlüsselgenerierungs-Nonce und Ableitungsschritte spezifiziert. Das bedeutet nicht, dass RFC 4285 unmöglich funktioniert. Es zeigt, wo der Interoperabilitätsvertrag endet. Ein Diagramm kann einen Schlüssel beim HA ankommen lassen; es standardisiert dadurch noch nicht Ableitung, Identitätsbindung, Geltungsbereich oder Übertragung zwischen unterschiedlichen Implementierungen. (RFC 5419, Abschnitt 7; RFC 3957, Abschnitt 5)

Die Aussage bleibt begrenzt. Die Authentifizierungsoption von RFC 4285 ist dadurch nicht automatisch fehlerhaft; ein lokales Profil kann die fehlenden Einzelheiten ergänzen. Wenn sie lokal bleiben, muss der Betreiber aber wissen, welche Komponenten sich daran halten: mobiles Gerät, AAA-Dienst, RADIUS-Attribute, HA und die Zuordnung von Teilnehmer zu dynamisch ausgewähltem HA. Das Nachrichtenformat allein bestätigt nicht die ganze Kette.

Während der Begründung änderte sich der technische Rahmen

RFC 5419 berücksichtigt seine eigene Chronologie. RFC 4877 spezifizierte 2007 den MIPv6-Betrieb mit IKEv2 und der überarbeiteten IPsec-Architektur. Laut RFC 5419 verbessert IKEv2 die Integration mit dem AAA-Backend; einige frühere Argumente für RFC 4285 waren damit überholt. Zudem hätten RFC 5026 und verwandte Arbeiten das Bootstrapping dynamischer Heimatadressen und Home Agents behandelt. Die Erklärung aus dem Jahr 2009 ist daher kein zeitloses Urteil über die einzig mögliche Architektur. (RFC 4877; RFC 5026; RFC 5419, Abschnitte 1, 5 und 9)

Die verbleibende Begründung war enger gefasst. Die Autoren hielten fest, dass manche Geräte in den betrachteten Umgebungen IKEv2 womöglich nicht unterstützten, zusätzliche Nachrichten auf einer knappen Funkschnittstelle ins Gewicht fallen könnten und Betreiber Identität sowie Dienstprofil im vorhandenen AAA-Modell halten wollten. Das sind Aussagen der Autoren über den damaligen Kontext. Sie zeigen weder, wie viele Geräte IKEv2 heute unterstützen, noch ob die genannten Netze noch laufen oder welche Option heute vorzuziehen wäre.

Auch die Authentifizierungsoption bringt Grenzen mit. RFC 5419 nennt zusätzlichen Schutz für die Routenoptimierung, fehlende Aushandlung kryptografischer Algorithmen, die Abhängigkeit der Replay-Abwehr von ausreichend synchronisierten Uhren sowie Datenschutzfragen bei einer sichtbaren langfristigen Network Access Identifier. Auch die MN–AAA-Assoziation wird außerhalb des Protokolls eingerichtet. Ein Betriebsprofil muss diese Bedingungen berücksichtigen; sie widerlegen für sich genommen nicht den Ansatz. (RFC 5419, Abschnitt 7)

Norm, Beispiel und Betrieb auseinanderhalten

Hier liegen drei verschiedene Belegebenen vor. RFC 4285 definiert Optionen und Verarbeitung. RFC 5419 bewahrt die historische Begründung und ein RADIUS-Beispiel. RFC 3957 bietet einen Vergleich zur Schlüsselableitung für Mobile IPv4; RFC 4877 beschreibt den IKEv2/IPsec-Pfad. Keines dieser Dokumente belegt, welche Implementierung in einem bestimmten Netz ausgeliefert wurde oder welches Profil dort heute läuft.

Eine Architekturprüfung sollte deshalb klären, woher das gemeinsame Geheimnis stammt, wie der Sitzungsschlüssel an Teilnehmer und ausgewählten HA gebunden wird, welches RADIUS-Attribut ihn überträgt, wie beide Seiten Lebensdauer und Replay-Zustand abstimmen und was geschieht, wenn AAA zustimmt, der HA aber die erwartete SA nicht anlegt. Stehen diese Antworten in einem Herstellerprofil, gehört es zur Sicherheitsarchitektur und braucht Versionierung, Tests und einen Migrationsplan.

Wenn IKEv2 die benötigte SA bereitstellt, müssen AAA-Integration und Unterstützung in den tatsächlich eingesetzten Geräte- und HA-Versionen nachgewiesen werden; eine veröffentlichte Spezifikation genügt dafür nicht.

Die bleibende Erkenntnis aus RFC 5419 lautet nicht, dass eine Option gewonnen hat. Eine zentrale Teilnehmerentscheidung und die kryptografische Beziehung zwischen MN und HA sind zwei verschiedene Infrastrukturteile. Ein standardisierter Austausch, ein ausdrücklich beschriebenes Betriebsprofil oder ein anderes Schlüsselmanagementprotokoll können sie verbinden. Das Wort „authentifiziert“ beweist jedoch nicht, dass der Schlüssel beim richtigen Endpunkt angekommen ist.

Quellen