Zusammenfassung

  • Eine Pflicht zur Implementierung schafft eine gemeinsame interoperable Möglichkeit. Sie belegt weder Aktivierung noch Aushandlung, korrekte Validierung oder Nutzung im untersuchten Datenstrom.
  • RFC 3631 ordnet den Mechanismus einem Bedrohungsmodell, einer Schutzschicht und -granularität, einem Vertrauensmodell, Schlüsselmanagement und vollständiger Nachrichtenabdeckung unter.
  • Belastbare Führungsevidenz verbindet Build, Konfiguration, Angebot, Auswahl, Referenzidentität, Vertrauenskette, Schlüssel, geschützte Einheiten, Autorisierung und beobachtetes Ergebnis.

Eine Normpflicht bekam den falschen Adressaten

Mandatory-to-implement soll verhindern, dass zwei Implementierungen ausschließlich nicht überlappende Optionen anbieten. Ein gemeinsamer Mechanismus bildet einen Interoperabilitätsboden. RFC 3631 macht aber deutlich, dass sich die Pflicht an Implementierer richtet.

Sie zwingt Betreiber nicht, den Mechanismus in jeder Umgebung zu aktivieren. Sie macht ihn nicht automatisch zur Voreinstellung und beweist keine Auswahl in einer Sitzung. Ein alter, schwach gewordener Pflichtalgorithmus kann zu Recht deaktiviert werden. RFC 3365, BCP 61, verbindet die Forderung nach starker Sicherheit mit genau dieser Unterscheidung zwischen Implementieren und Benutzen.

Ein Audit benötigt daher getrennte Zustände: Fähigkeit im ausgelieferten Build, Zulassung durch Konfiguration, Angebot durch den Peer, ausgehandelter Wert, tatsächliche Verwendung im betroffenen Fluss und Übereinstimmung mit der zu diesem Zeitpunkt gültigen Policy. Ein Datenblatt beantwortet nur die erste Frage.

Das schützt auch eine saubere Stilllegung. Eine Altoption kann im Code verbleiben, ohne exponiert zu sein. Umgekehrt kann eine Policy ihre Abschaltung verlangen, während unveränderte Instanzen sie weiter anbieten. Codeinventar und Laufzeitbeobachtung dürfen sich widersprechen, ohne dass eines von beiden gelöscht wird.

Historischer Text, bleibende Trennung

RFC 3631 erschien im Dezember 2003 als Informational RFC im Stream des Internet Architecture Board. Es ist kein Internet Standard. Die RFC-Editor-Seite und der IETF Datatracker halten diesen Status fest. Die Dokumenthistorie belegt Publikationsschritte, keine Einführung, und die Errata-Suche zertifiziert keine Implementierung.

Konkrete Algorithmusbewertungen stammen aus dem Jahr 2003. Aktuelle TLS-Mechanik steht in RFC 8446, heutige TLS/DTLS-Empfehlungen in RFC 9325, die spätere IPsec-Architektur in RFC 4301. Der Artikel übernimmt keine alte Kryptografieempfehlung.

Beständig ist die architektonische Warnung. Sicherheitsmechanismen lassen sich nicht als Zusatzstoff über ein fertiges Protokoll streuen. Eine korrekte kryptografische Implementierung kann falsche semantische Annahmen über Identität, Vollständigkeit oder Berechtigung nicht reparieren.

Das Bedrohungsmodell bestimmt die Anforderung

RFC 3631 fragt zuerst, wer welche Ressource mit welchen Mitteln und aus welcher Position angreifen kann. Ein öffentlich lesbarer Dienst benötigt möglicherweise wenig Vertraulichkeit, aber starke Integrität. Dasselbe System kann am Backbone ein attraktiverer Überwachungspunkt sein als in einem isolierten Randnetz.

RFC 3552 beschreibt das Bedrohungsmodell als Annahmen über Fähigkeiten und als Abgrenzung behandelter und ausgeschlossener Gefahren. Anwendungsprotokolle dürfen nicht unterstellen, alle Angreifer seien off-path. Ein ursprünglich begrenztes Einsatzgebiet muss auch bei späterer Ausweitung betrachtet werden.

Der Bericht des IAB Security Architecture Workshop, RFC 2316, verlangte schon zuvor, Bedrohungen, Gegenmaßnahmen und Grenzen in RFCs sinnvoll auszuweisen. Das ist Prozessevidenz, keine Aussage über ein Produkt.

Vor der Technikauswahl stehen Asset, Handlung, Schaden, on-path- und off-path-Angreifer, Insider, kompromittierter Endpunkt, Schutzdauer und gewünschte Eigenschaft: Vertraulichkeit, Integrität, Peer- oder Ursprungsauthentisierung, Replay-Schutz, Verfügbarkeit oder Autorisierung. „Starke Verschlüsselung“ benennt keinen dieser Zusammenhänge.

Die Schicht legt den Gegenstand fest

Ein Mechanismus auf niedriger Ebene deckt viele höhere Protokolle ab, besitzt aber weniger Anwendungskontext. Link-Verschlüsselung schützt einen Link. IPsec schützt ausgewählten Verkehr zwischen Hosts oder Gateways. TLS stellt einer Anwendung einen geschützten Kanal und Peer-Evidenz bereit. Eine Objektsignatur kann Speicherung und Weiterleitung überdauern.

Die Breite ist keine Rangliste. Ein Gateway-Tunnel authentisiert keinen inneren Benutzer. Ein TLS-Kanal bewahrt ein exportiertes Dokument nach dem Transport nicht automatisch. Eine gültige Objektsignatur kann eine unberechtigte oder sachlich falsche Anweisung unverändert erhalten.

Der Nachweis muss die Einheit nennen: Link, Paketklasse, Host, Gateway, Verbindung, Anwendungsprincipal, Nachricht oder dauerhaftes Objekt. Ebenso wichtig sind die Lücken zwischen diesen Einheiten.

RFC 4301 macht diese Grenze für IPsec prüfbar. Sicherheitsdienste hängen von Protokoll, Modus, SA-Endpunkten, Schlüsseln und Policy ab. Verkehr kann geschützt, verworfen oder umgangen werden. Ein aktiver Tunnel belegt nicht, dass das umstrittene Paket die Protect-Regel traf. SPD-Version, Selektoren, SA, Zähler, Paket- oder Flusskorrelation und die innere Anwendungsentscheidung gehören zusammen.

Aushandlung ist eine laufende Policy-Entscheidung

Nach RFC 3631 besitzt SASL die Eigenschaften des tatsächlich ausgehandelten Mechanismus. Bei GSS-API muss der zugrunde liegende Mechanismus gesondert bewertet werden. Ein Frameworkname sagt nichts Endgültiges über gegenseitige Authentisierung, Schutz nachfolgender Nachrichten, Channel Binding oder Replay-Widerstand.

Das Protokoll der Entscheidung umfasst Angebot, Auswahl, Parameter, Bindung, Rückfall und resultierende Eigenschaften. Eine syntaktisch gültige Wahl kann gegen lokale Policy verstoßen. Kompatibilität schafft wirtschaftlichen Druck, alte Optionen offen zu halten; daraus entsteht die Downgrade-Fläche.

TLS 1.3 bleibt gegenüber dem Anwendungsprotokoll unabhängig. Anwendung und Profil entscheiden, wie TLS beginnt und wie Identitäten genutzt werden. Version, Cipher Suite, Clientauthentisierung, ALPN, Wiederaufnahme und 0-RTT ändern die Aussage. 0-RTT hat Replay-Grenzen; eine nicht wiederholbare Geschäftsanweisung braucht zusätzlichen Schutz.

Auch das Ende zählt. Wenn eine Anwendung einen vollständigen Strom benötigt, bestimmen close_notify und Abbruchbehandlung, ob sie Vollständigkeit oder Kürzung annimmt. Integritätsgeschützte Records können gemeinsam eine unvollständige Transaktion bilden.

Ein gültiges Zertifikat kennt den beabsichtigten Namen nicht

RFC 9325 betont die Hostnamenprüfung. Eine Zertifikatskette kann gültig sein und der Peer kann den privaten Schlüssel besitzen, ohne das gewünschte Ziel zu sein. Die Referenzidentität kommt vor der Verbindung aus Konfiguration, Discovery oder Nutzerauswahl.

Zu speichern sind Referenzname, Zertifikatsnamen, Matching-Regel, Trust Anchors, Validierungszeit, Statusdaten, Ausnahmen und Ergebnis. Würde der präsentierte Peer selbst definieren, nach welchem Namen gesucht wurde, wäre die Prüfung zirkulär.

Danach folgt die Autorisierung. Serverauthentisierung ist keine Clientauthentisierung. Ein Clientzertifikat kann ein Gerät statt eines Menschen identifizieren. Selbst eine richtige Identität hat nicht automatisch das Recht, eine Ressource zu ändern.

RFC 3631 stellt hierarchische Zertifikate und das PGP-Web-of-Trust gegenüber. Beide benötigen einen lokal akzeptierten Ausgangspunkt und verlässliche relevante Kanten. Die Signatur belegt die Handlung eines Schlüssels. Die Relying-Party-Policy entscheidet, warum sie für diesen Zweck Autorität besitzt.

Der erste MAC schützt nicht die letzte Nachricht

Das HMAC-Beispiel in RFC 3631 markiert eine zeitliche Grenze. Eine Shared-Secret-Challenge kann den Verbindungsbeginn authentisieren und alte Sitzungen abwehren. Bleiben spätere Protokolleinheiten ungeschützt, kann die Sitzung nach dem Check übernommen werden.

Ein Coverage-Record nennt Methode, Ziel, Header, Body, Nonce, Sequenz und Antwort, die im MAC oder in der Signatur enthalten sind. Er zeigt, ob jede zustandsändernde Nachricht geschützt wurde, ob eine neue Verbindung alte Berechtigung erbte und ob die Abschlussbestätigung im selben Kontext lag.

„MAC gültig“ beschreibt Bytes und einen Schlüssel. Eine Autorisierung benötigt Principal, Ressource, Scope, Frische und Policy. Wer das Prüfergebnis direkt in ein Permit verwandelt, erzeugt Entscheidungsdaten, die nie Teil der kryptografischen Eingabe waren.

Schlüsselverwaltung entscheidet über die Zeitachse

RFC 4107, BCP 107, trennt automatische und manuelle Schlüsselverwaltung. Automatisierung kann Peer-Liveness bestätigen, frische Schlüssel ableiten und Rotation skalieren. Manuelle Schlüssel sind nur unter begrenzten Bedingungen vertretbar und benötigen Kennung, Übergang, Austausch und Kompromissbehandlung.

Der Datensatz enthält Herkunft, Erzeugung, Speichergrenze, Verteilung, Peerbindung, Zweck, Alter, Rotation, Widerruf, Vernichtung und Kompromissstatus. Dieselbe Suite mit ephemerem Schlüssel und mit jahrelang kopiertem Shared Secret hat ein anderes Risikoprofil. TLS-Ticket-Schlüssel und Wiederaufnahme können Forward-Secrecy-Erwartungen verändern, ohne den Protokollnamen zu ändern.

Ohne Austausch- und Austrittsweg wird der erste Schlüssel zur unbefristeten Befugnis. Der Mechanismus bleibt verfügbar, während die Organisation nicht mehr zeigen kann, wer den Zugang verloren hat.

Topologie ist eine Sicherheitskonfiguration

RFC 3631 nennt die Firewall eine topologische Verteidigung. Sie setzt eine erkennbare Innen-Außen-Grenze voraus und stoppt für sich keinen Insider. Tunnel, Funk, Direktverbindungen, alternative Routen oder kompromittierte Endpunkte können die Grenze verändern, ohne dass die Regel anders aussieht.

Adress- und namensbasierte Authentisierung hängen ebenfalls von Routing, DHCP, Proxies, Spoofing und DNS ab. DNSSEC schützt signierte DNS-Daten vor Veränderung; es macht eine falsche Grundzuordnung nicht wahr und eine Namensauflösung nicht zur Autorisierung.

Topologiestand, Ausweichpfade, Verwaltungsdomänen und Ausnahmen müssen zusammen mit der Kryptopolicy versioniert werden. Eine unveränderte Firewallregel kann ihre Bedeutung verlieren, wenn der Verkehr einen neuen Weg findet.

Der Sicherheitsbeleg ist eine Kette, kein Badge

Lu Hengs Texte über Realitätsebenen und Vorrang von Running Code trennen formale Spezifikation, Fähigkeit, Konfiguration, Auswahl, Validierung, Entscheidung und Wirkung. Minimum Initial Specification erlaubt eine gemeinsame Evidenzschnittstelle, ohne der Anwendung künftige Entscheidungen zu nehmen. Authority and Belief verlangt für jede Aussage Aussteller, Scope und Grenze.

Für eine folgenreiche Aktion werden Ressource und Bedrohung, erforderliche Eigenschaft, Build, Konfiguration, Angebot und Wahl, Referenzidentität, Credential, Vertrauenspfad, Schlüssel, geschützte Bytes, Anwendungsprincipal, Autorisierungsregel, Permit oder Deny und beobachtetes Netz- und Geschäftsergebnis verbunden. Alert, Fallback, Bypass, Replay-Ablehnung, Ablauf, Namensfehler, Kürzung und Ausnahme gehören dazu.

Die Implementierung im Einstieg erfüllte ihre Pflicht. Der Fehler lag darin, diese Softwareeigenschaft ohne Laufzeitnachweis auf jede Verbindung zu übertragen. Konformität ist ein Anfangsbeleg, kein Endurteil.

Quellen

  1. RFC 3631 — Security Mechanisms for the Internet
  2. RFC 3631 als Klartext
  3. RFC-Editor-Information zu RFC 3631
  4. IETF-Datatracker zu RFC 3631
  5. IETF-Dokumenthistorie zu RFC 3631
  6. Errata-Suche zu RFC 3631
  7. RFC 2316 — IAB Security Architecture Workshop
  8. RFC 3365 — Anforderungen an starke Sicherheit
  9. RFC 3552 — Security Considerations
  10. RFC 4107 — kryptografische Schlüsselverwaltung
  11. RFC 4301 — IPsec-Architektur
  12. RFC 8446 — TLS 1.3
  13. RFC 9325 — sicherer Einsatz von TLS und DTLS
  14. Lu Heng — Running Code Primary
  15. Lu Heng — Minimum Initial Specification
  16. Lu Heng — On Reality Layers
  17. Lu Heng — On Authority and Belief