Zusammenfassung

  • Eine kryptografisch erzeugte Adresse bindet einen öffentlichen Schlüssel an die IPv6-Schnittstellenkennung. Eine passende Signatur belegt den Zugriff auf den privaten Schlüssel, nicht eine reale Identität oder Routerbefugnis.
  • Für die Routerprüfung brauchte ein Host weiterhin einen Zertifikatspfad zu einem bereits lokal eingerichteten Vertrauensanker. SEND beseitigte diesen Ausgangspunkt nicht.

Bevor IPv6-Verkehr das lokale Netz verlässt, muss ein Rechner Nachbarn auf der Verbindung erkennen: Er löst Link-Layer-Adressen auf, findet Router und prüft deren Erreichbarkeit. Eine gefälschte Nachricht kann diese frühen Entscheidungen beeinflussen. RFC 4861 definiert die Funktionen von Neighbor Discovery. IPsec war als Schutz vorgesehen, doch die ursprünglichen Dokumente erklärten den Einsatz nicht hinreichend konkret. Die manuelle Einrichtung von Security Associations für viele mögliche Gegenstellen erschien für die meisten Umgebungen unpraktisch, hält RFC 3971 fest.

SEND versucht nicht, diesen gesamten Vertrauensbedarf in ein einziges Zertifikat zu packen. Für die Frage, ob ein Absender den privaten Schlüssel zu seiner Adresse kontrolliert, nutzt es eine Cryptographically Generated Address (CGA). RFC 3972 leitet die Schnittstellenkennung aus einem öffentlichen Schlüssel und Zusatzparametern ab. Der Empfänger berechnet die Bindung erneut und prüft die Signatur. Für diese Beziehung zwischen Adresse und Schlüssel braucht es keine Zertifizierungsstelle.

Der Nachweis bleibt bewusst begrenzt. RFC 3972 erlaubt jedem, unter einem Subnetzpräfix mit dem eigenen Schlüssel eine neue CGA zu erzeugen. Das Verfahren verhindert, dass dieser Akteur für eine bereits von jemand anderem erzeugte CGA unterschreibt. Es benennt aber keine Person, belegt keine Vergabe des Präfixes und autorisiert keinen Router. Schlüsselkontrolle und Routerrolle sind unterschiedliche Aussagen.

Für Router Discovery muss der Host einen anderen Pfad prüfen: Das Routerzertifikat muss sich bis zu einem Vertrauensanker verifizieren lassen, den der Host bereits konfiguriert hat. SENDs Verfahren zur Entdeckung einer Zertifizierungskette kann deren Beschaffung erleichtern. Es macht einen unbekannten Aussteller jedoch nicht zur vertrauenswürdigen Wurzel. „Ohne Zertifikatsinfrastruktur“ trifft somit auf den CGA-Nachweis zu, nicht auf die gesamte Routerautorisierung.

Spätere Standards konkretisierten beide Seiten. RFC 6494 legt ein SEND-Zertifikatsprofil auf Grundlage von Ressourcenzertifikaten fest; RFC 6495 definiert einen SEND-Namenstyp für Subject Key Identifier. RFC 6980 schränkt außerdem die IPv6-Fragmentierung bestimmter ND- und SEND-Nachrichten ein, weil Fragment-Header Überwachung oder Filter umgehen konnten. Das sind dokumentierte Änderungen an Zertifikaten und Paketbehandlung, keine Zahlen zur Verbreitung oder zum Sicherheitsgewinn.

Die Geschichte von RFC 3971 handelt daher nicht davon, dass Kryptografie Vertrauen ersetzt. Sie zeigt eine engere Architektur: Ein Schlüssel belegt eine Adressbindung; eine konfigurierte Wurzel autorisiert Router.