Zusammenfassung

  • RFC 9645 definiert wiederverwendbare YANG-Gruppierungen für Client- und Serveridentität, Peer-Authentisierung, Hello-Parameter und Keepalives. Der bewusst minimale gemeinsame Nenner ist kein vollständiges Sitzungsprotokoll.
  • Ein konfiguriertes Zertifikat, ein Raw Public Key oder PSK belegt eine genehmigte Möglichkeit. Daraus folgt nicht, was der Peer anforderte, welches Material präsentiert und geprüft wurde, ob eine Sitzung wiederaufgenommen wurde oder welchen Principal die Anwendung anerkannte.
  • Belastbare Aussagen erfordern einen korrelierten Laufzeitbeleg von Modell- und Konfigurationsrevision über den tatsächlich ausgeführten Handshake-Zweig bis zu Peer-Identität, Validierung, optionaler Client-Authentisierung und Anwendungsergebnis.

Ordnungsgemäße Änderung, unvollständige Rekonstruktion

Nach einem privilegierten Eingriff liegen sämtliche klassischen Nachweise vor: genehmigtes Change-Ticket, gültiger YANG-Baum, auflösbare Keystore- und Truststore-Referenzen, freigegebene TLS-Versionen und ein erwartetes Serverzertifikat. Dennoch kann die Verbindung über einen anderen Listener, einen Raw Public Key, einen Notfall-PSK oder eine Wiederaufnahme gelaufen sein.

RFC 9645 verspricht keine andere Leistung. Es definiert ietf-tls-common, ietf-tls-client und ietf-tls-server sowie das IANA-gepflegte Enumerationsmodul für TLS Cipher Suites. Die Client- und Servergruppierungen beschränken sich auf TLS; Adresse, Port und Aufbau der Transportverbindung bleiben den konsumierenden Modellen überlassen. Die generischen Modelle werden ausdrücklich als kleinster gemeinsamer Nenner und nicht als vollständige TLS-Abbildung beschrieben.

Diese Grenze ist architektonisch wertvoll. Ein gemeinsames Datenmodell kann die Absicht präzisieren, ohne die Laufzeitentscheidung einer Bibliothek oder die Autorisierung einer Anwendung zu vereinnahmen. Ein Audit wird erst dann irreführend, wenn es aus einer angenommenen Konfiguration einen beobachteten Vorgang macht.

Jeder Identitätszweig trägt eine andere Beweislast

Zertifikat, Raw Public Key, TLS-1.2-PSK und externer TLS-1.3-PSK sind keine austauschbaren Darstellungen derselben Identität.

Beim Zertifikat wirken Kette, Referenzname, Zeit, Key Usage, Signaturalgorithmen, Vertrauensanker und lokale Policy zusammen. Ein Raw Public Key besitzt keine entsprechende Zertifikatskette und wird typischerweise exakt gegen einen bekannten Schlüssel geprüft. Der TLS-1.2-PSK folgt älteren Identitäts- und Geheimnisregeln. Der externe TLS-1.3-PSK enthält External Identity, Hash sowie optionale Kontext- und Zielparameter.

RFC 9257 weist darauf hin, dass PSK-Kennungen sichtbar und korrelierbar sein können. Mitglieder einer Gruppe mit demselben PSK können einander imitieren. RFC 9258 unterscheidet zwischen einem kontextgebunden importierten PSK und einem kontextfreien PSK. „PSK erfolgreich“ kann daher Gruppenzugehörigkeit belegen, ohne einen einzelnen Akteur nachzuweisen.

Der Laufzeitbeleg muss Zweig, PSK-Klasse und Kontextstatus festhalten und das tatsächlich geladene Material durch geschützte Fingerprints oder Versionen identifizieren. Das Geheimnis selbst darf nicht zum Protokolldatum werden.

Server- und Client-Authentisierung sind getrennte Entscheidungen

Die Clientgruppierung trennt client-identity von server-authentication. Die Clientidentität ist optional, weil eine höhere Protokollschicht authentisieren kann. Selbst wenn sie konfiguriert ist, wird sie auf TLS-Ebene erst präsentiert, wenn der Server sie beim Sitzungsaufbau anfordert.

Die Servergruppierung trennt entsprechend server-identity vom optionalen Container client-authentication. Ohne diesen sollte der Server keine Client-Credentials anfordern. Mit ihm bilden CA-Zertifikate, exakt benannte End-Entity-Zertifikate, Raw Public Keys und PSK-Mechanismen additive Akzeptanzmöglichkeiten.

Das übliche Feld „mTLS aktiv“ verdeckt deshalb mehrere Zustandsübergänge: Fähigkeit zur Anforderung, tatsächliche Anforderung, Präsentation, Validierung, Abbildung auf einen Application Principal und Autorisierung. Ein einziges Boolean kann nicht unterscheiden, ob eine Anforderung fehlte, der Client nicht antwortete, die Prüfung scheiterte oder die Anwendung später ablehnte.

Der Beleg muss diese Übergänge einzeln ausweisen. Nur dann bleibt sichtbar, wo die Zuständigkeit von TLS endet und die der Anwendung beginnt.

Wiederaufnahme ist keine erneute Zertifikatsprüfung

Die aktuelle TLS-1.3-Spezifikation RFC 9846 behandelt Versionen, Signaturalgorithmen, Gruppen, Key Shares und PSK-Identitäten als getrennte Eingaben. Der Server wählt einen kompatiblen PSK und eine Cipher Suite und verifiziert einen Binder, der den PSK an den aktuellen Transcript bindet.

Diese Bindung schützt den gegenwärtigen Handshake. Sie beweist nicht, dass das Zertifikat aus der ursprünglichen Verbindung erneut präsentiert und validiert wurde. Eine wiederaufgenommene Sitzung kann früher etablierten Sicherheitskontext übernehmen. Wer aus der statischen Konfiguration das Zertifikat in den Bericht kopiert, erzeugt einen stärkeren Nachweis, als die Sitzung geliefert hat.

Auch externer PSK und Resumption-PSK müssen getrennt werden. Der eine stammt aus externer Provisionierung, der andere aus einer früheren Sitzung. Bei Early Data können relevante Anwendungsbytes vor dem gewöhnlichen Bestätigungspunkt gesendet werden. Der finale Erfolg allein sagt dann nichts über die Replay- und Autorisierungsgrenze der Operation.

Der Beleg muss Full, Resumed oder Early Data benennen und Herkunft sowie Kontext des PSK angeben, ohne Schlüsselmaterial offenzulegen.

Version und Cipher Suite sind kein Identitätsurteil

Mit hello-params-grouping lassen sich minimale und maximale TLS-Version sowie eine benutzergeordnete Cipher-Suite-Liste konfigurieren. Optionaler Supported-Algorithm-State beschreibt Implementierungsfähigkeit. Diese Angaben charakterisieren den kryptografischen Kanal, nicht den Peer.

Die IANA warnt, dass Algorithmen mit der Zeit schwächer werden und Registrierung keine Empfehlung ist. TLS-1.3-Suites haben zudem eine andere Semantik als Suites früherer Versionen. RFC 9325 gibt Deployment-Empfehlungen; RFC 9852 verlangt in seinem Geltungsbereich TLS-1.3-Unterstützung für neue Protokolle. Ein Bezeichner kann bestehen bleiben, während sich die lokale Zulässigkeit ändert.

Negotiated Version und Cipher Suite gehören in den Beleg, aber getrennt von Identitätsmodus, präsentierter Credential und Validierung. „TLS 1.3 mit freigegebener Suite“ beweist nicht, ob Zertifikat, Raw Public Key, External PSK oder Resumption die Identität trug.

Von der Änderungsfreigabe zum Ausführungsbeleg

RFC 8342 trennt Intended Configuration und Operational State. RFC 8341 beschränkt Änderungen an sensiblen Knoten. RFC 9641 und RFC 9642 stellen Truststore- und Keystore-Referenzen bereit. Jede Ebene schafft einen notwendigen Nachweis; keine erzeugt das Ergebnis der nächsten.

Eine Keystore-Referenz kann auflösbar sein, obwohl eine andere Credential verwendet wird. Ein Truststore kann vorhanden sein, obwohl der Peer kein Zertifikat sendet. Applied State kann einen Listener betreffen, den die Sitzung nie erreicht. TLS kann einen Schlüssel validieren, den die Anwendung keinem Konto zuordnet. Ein autorisierter Principal kann schließlich an der Operation scheitern.

Heng Lus Trennung von symbolischer Autorität und operativer Wirklichkeit liefert die Reihenfolge: Das Modell beherrscht die Sprache, Change Control die Absicht, der TLS-Stack den ausgeführten Zweig und die Anwendung Bedeutung sowie Ergebnis.

Ein Mindestbeleg umfasst daher:

  • RFC-/YANG-Revision, Features, Deviations und konsumierendes Modell;
  • angewandte Konfigurationsrevision, Datastore-Herkunft, Freigabe und Aktivierungszeit;
  • Identitätszweig und tatsächlich aufgelöste Keystore-/Truststore-Referenzen;
  • geschützte Fingerprints oder Versionen der geladenen Credential- und Trust-Daten;
  • Session-Korrelation und belastbare Zeitstempel;
  • negotiated Version und Cipher Suite, getrennt vom Identitätsmodus;
  • Full, Resumed oder Early Data sowie Herkunft und Kontext des PSK;
  • präsentierte Peer-Identität, Prüfverfahren, Ergebnis und Unsicherheit;
  • Anforderung, Antwort, Prüfung und Application Principal der Client-Authentisierung;
  • Abschluss, Alerts, Retries und Fallback-Historie;
  • Anwendungsautorisierung, Operation, Abnahmekriterium und Ergebnis;
  • unbekannte Felder und die Instanz, die die abschließende Aussage freigibt.

Keiner der zitierten RFCs schreibt dieses Einheitsformat vor. Es ist ein Betriebsmodell aus ihren Grenzen. Es erlaubt eine enge, überprüfbare Aussage: Für diese Sitzung und Operation führte diese angewandte Konfiguration zu diesem Authentisierungszweig, dieser validierten Identität, diesem Principal und diesem Ergebnis.

Quellen

  1. Minimale Anfangsspezifikation
  2. Realitätsebenen und symbolische Macht
  3. Vorrang des laufenden Codes
  4. RFC-9645-Dokumenthistorie
  5. RFC-9645-Informationsseite
  6. RFC 9645 HTML
  7. RFC 9645 Text
  8. RFC 9645 XML
  9. RFC-9645-Inline-Errata
  10. IANA TLS Parameters
  11. IANA YANG-Modul für TLS Cipher Suites
  12. RFC 9641: Truststore-Modell
  13. RFC 9642: Keystore-Modell
  14. RFC 9846: aktuelles TLS 1.3
  15. RFC 9852: TLS 1.3 für neue Protokolle
  16. RFC 9325: sicherer TLS-Einsatz
  17. RFC 9257: Leitlinien für External PSKs
  18. RFC 9258: Import externer PSKs
  19. RFC 8341: Zugriffskontrolle für Netzkonfiguration
  20. RFC 8342: Network Management Datastore Architecture