Zusammenfassung

  • RFC 5386 nutzte eine vom Peer gelieferte rohe öffentliche RSA-Schlüsselstruktur, um eine IKEv2-Signatur zu prüfen, ohne eine externe Namensbindung des Schlüssels zu behaupten.
  • Nicht-BTNS-PAD-Einträge mussten zuerst gelten. Passte ein Peer zu einer bekannten Identität und scheiterte an deren Authentisierung, war Ablehnung zwingend; der Wildcard-Eintrag durfte ihn nicht übernehmen.
  • RFC 7670 modernisierte später die Rohschlüssel-Kodierung. Weder diese Modernisierung noch eine installierte SA ersetzt die ausdrückliche PAD-, Selektor- und SPD-Autorisierung.

Die historische Kodierung war Teil der Betriebsbedingung

RFC 5386 verlangte von einem Knoten, der von seinem Gegenüber als BTNS behandelt werden wollte, einen bare public key CERT payload. Im Stand von 2008 war dafür in RFC 4306 nur ein roher RSA-Schlüssel definiert. BTNS funktionierte in diesem beschriebenen Pfad daher mit RSA.

Dieser Satz ist keine ewige Produkteigenschaft. RFC 7296 entfernte die frühere Raw-RSA-Form aus der IKEv2-Basisspezifikation. RFC 7670 führte 2016 einen algorithmusunabhängigen Raw-Public-Key-Payload mit PKIX-SubjectPublicKeyInfo ein. RFC 7427 hatte die Signaturauthentisierung für weitere Schlüsseltypen erweitert.

Ein historischer Entwurf darf deshalb nicht als heutige Interoperabilitätsmatrix gelesen werden. Wer BTNS-Verhalten in einer laufenden Implementierung behauptet, muss Version, Zertifikatskodierung, AUTH-Methode und konkrete Policy belegen. Der RFC-Titel allein sagt nicht, welche spätere Bausteinkombination tatsächlich implementiert ist.

Die Standardentwicklung macht aber eine konstante Grenze sichtbar. Eine andere Schlüsselhülle erzeugt keine äußere Identität. RFC 7670 fordert bei Raw Public Keys ein Out-of-Band-Verfahren, wenn ein Deployment von der Authentizität des Schlüssels überzeugt sein will. Der Schlüssel kann selbst als IKE-Identität dienen; seine Zuordnung zu einem Namen bleibt ein weiterer Beleg.

RFC 5386 authentisierte den Besitz, nicht den Namen

Der Peer lieferte einen öffentlichen Schlüssel und signierte den IKEv2-Austausch mit dem zugehörigen privaten Schlüssel. Eine gültige AUTH-Signatur bewies, dass der Handelnde den privaten Schlüssel kontrollierte und dass die geschützten Austauschdaten dazu passten.

RFC 5386 ergänzte einen lokalen ID-Typ PUBLICKEY. Sein Wert war der Schlüssel, der Typ ging nicht über den Draht. Erst wenn kein gewöhnlicher PAD-Eintrag zur behaupteten Peer-ID passte, durfte die Implementierung die lokale Identität in PUBLICKEY überführen und BTNS-Einträge prüfen.

Die Formulierung, ein BTNS-Peer werde durch die Signatur „authenticated“, ist in diesem Modell eng. Sie bedeutet nicht, dass eine CA, ein DNS-Name, eine Inventardatenbank oder ein Arbeitgeber den Schlüsselinhaber bestätigt hat. Ein Audit sollte daher signature_valid und external_binding_valid niemals in ein Feld verschmelzen.

RFC 7619 formulierte später einen noch ausdrücklicher anonymen IKEv2-Pfad mit NULL Authentication und ID_NULL. Auch dort bindet ein korrektes AUTH payload die IKE-Nachrichten kryptografisch, während die Peer-ID unbestätigt und für Vertrauensentscheidungen unbrauchbar bleibt. Unterschiedliche Mechanismen führen zur gleichen Beweispflicht: die genaue Aussage muss benannt werden.

Ein bekannter Fehler durfte nicht anonym werden

Die PAD ist eine geordnete Liste. RFC 5386 ordnete alle BTNS-Einträge logisch hinter den Nicht-BTNS-Einträgen an. Höchstens ein Wildcard-Eintrag war zulässig, und er musste der letzte sein.

Zunächst wird mit der vom Peer behaupteten Identität gesucht. Passt ein bekannter Eintrag, besitzt er die Entscheidung. Schlägt die dort geforderte Authentisierung fehl, muss der Knoten die IKE-SA ablehnen.

Nur wenn kein bekannter Eintrag passt, beginnt die Suche nach PUBLICKEY. Das trennt „unbekannt“ von „bekannt, aber widerlegt“. Würde die Engine nach dem Fehlschlag weitersuchen, könnte ein Angreifer die bekannte Identität eines Partners nennen, an dessen Credential scheitern und sich anschließend vom anonymen Wildcard akzeptieren lassen.

Der letzte Platz des Wildcards ist daher eine Downgrade-Sperre. Er ist nicht bloß die übliche Position einer Default-Regel. Seine Zuständigkeit beginnt erst außerhalb der benannten Beziehungen.

Ein aussagekräftiger Test braucht alle drei Pfade: gültiger bekannter Peer, zulässiger unbekannter Schlüssel und Angreifer mit bekannter Behauptung, aber falschem Credential. Nur der zweite darf BTNS erreichen; der dritte muss am ersten Eintrag enden.

Child-SA-Selektoren bildeten eine zweite Grenze

Peer-Zulassung und Verkehrsvertretung sind verschiedene Entscheidungen. Ein anonymer Schlüssel, der eine IKE-SA aufbauen darf, soll nicht automatisch eine Adresse oder ein Netz hinter einem authentisierten Gateway vertreten können.

RFC 5386 verlangte daher nicht überlappende Child-SA-ID-Beschränkungen. Beim Aushandeln einer Child SA kann die PAD erneut geprüft werden. Behauptete Traffic Selectors eines BTNS-Peers dürfen nicht mit Bereichen kollidieren, die Nicht-BTNS-Einträgen gehören.

Im Gateway-Beispiel wird ein Angreifer, der die Adresse eines bekannten Peers beansprucht, entweder vom bekannten Eintrag erfasst und an der Authentisierung abgewiesen oder als anonymer Schlüssel zugelassen, aber am Selektor gehindert. Die schwache Zulassung erhält keinen Umweg zur starken Identität.

RFC 7619 warnt bei NULL Authentication vor demselben Strukturfehler. Ein anonymer Peer könnte einen Selektor für den DNS-Server des Gegenübers verlangen und dessen Verkehr umleiten. Isolierung und begrenzte Zuweisung bleiben notwendig, auch wenn die SA danach korrekt verschlüsselt.

Die SPD machte Anonymität zum lokalen Opt-in

RFC 5386 ergänzte das Flag BTNS_OK. Verkehr von einem BTNS-Peer passt nur auf SPD-Einträge, die es setzen. Ein Produktfeature öffnet dadurch nicht automatisch alle Schutzregeln.

Ein Betreiber kann einen öffentlichen Dienst für anonyme Netzwerkschlüssel freigeben und Verwaltungs- oder Partnerverkehr bei klassischer Authentisierung belassen. Die Erlaubnis hängt an der lokalen Verkehrsklasse, nicht am Ruf des Peers.

Die Entscheidungskette lautet deshalb: PAD-Regime für den Peer, Authentisierungsergebnis, zulässige Child-SA-Identitäten, SPD-Regel und tatsächliche Paketverarbeitung. Eine vorhandene SAD-Zeile oder ein grüner Tunnel kann keine dieser Übergänge ersetzen.

Auch RFC 7619 verlangt für unauthentisierte Nutzer ein ausdrückliches SPD-Flag und rät davon ab, unauthentisiertes IKE für Selektoren zuzulassen, für die authentisiertes IKE möglich ist. Die spätere Spezifikation bewahrt das Prinzip des engsten lokalen Grants.

Kontinuität endete an der SA-Grenze

RFC 5387 bezeichnet die schwache Herkunftsaussage von Stand-Alone BTNS als „continuity of association“. Innerhalb einer SA kann derselbe unauthentisierte Ursprung fortbestehen. Wenn die Eröffnung nicht von einem MITM manipuliert wurde, bieten ESP oder AH reale Integrität, Vertraulichkeit und Replay-Abwehr.

Bei der ersten Eröffnung bleibt ein aktiver MITM möglich. Beim Rekey kann ein weiterer Übergang entstehen. Zwei intern gültige SAs beweisen ohne Verbindung nicht denselben Peer.

Connection latching bindet einen höheren Flow an eine Folge ähnlicher SAs. Channel binding nimmt Kanaleigenschaften in die höhere Authentisierung auf. Channel-Bound BTNS kann dadurch einen Vermittler erkennen, der zwei SAs verkettet.

Die Erkennung erfolgt aber nach dem unauthentisierten IKE-Erfolg. Ressourcen sind bereits angelegt; ein ungeeignetes höheres Protokoll könnte Passwortmaterial offenbaren, bevor es den MITM erkennt. RFC 5387 schließt solche riskanten Kombinationen aus. Späte Erkennung ist keine rückwirkende Verhinderung.

Die Quellen beweisen keine aktuelle Installation

RFC 5386 definiert keinen automatischen Rückfall in ungeschütztes IP und spezifiziert weder Leap of Faith noch Latching vollständig. RFC 5387 empfiehlt BTNS als Ersatz für keine Sicherheit, nicht für stärkere Sicherheit.

Die Quellen belegen diese Architektur und ihre Entwicklung. Sie belegen keine heutige Produktunterstützung, keine Verbreitung, keinen Angriff und keine Wirksamkeit einer konkreten Konfiguration. Dafür wären Build, Laufzeitpolicy, Trace, Paketbeobachtung und Anwendungsergebnis erforderlich.

Lu Hengs Trennung von Symbol, Ausführung und Wirkung passt hier genau: Schlüsselbytes, Signatur, PAD-Zweig, SPD-Grant, SA, Paket und Anwendungsergebnis sind verschiedene Realitäten. Der Standardwechsel kann die Kodierung modernisieren. Er darf nicht die fehlende Autorität erfinden.