Zusammenfassung

  • RFC 5197 ordnet MIKEY-Verfahren nach Voraussetzungen und Eigenschaften. RSA-R behebt die fehlende Vorabkenntnis des Responder-Zertifikats, liefert aber kein echtes Perfect Forward Secrecy.
  • Der Betriebsnachweis muss Zertifikatsentdeckung, Identitätsprüfung, Beiträge zur Schlüsselbildung, PFS, Replay-Zustand, TGK/TEK-Grenzen und den Zeitpunkt der Medienbereitschaft getrennt halten.

Das gelöste Problem war Adressierung

Beim klassischen RSA-Modus erzeugt der Initiator die TGK, schützt sie mit einem Envelope Key und verschlüsselt diesen für den Empfänger. Dafür muss das Zertifikat des Responders vor dem Austausch verfügbar sein. Das passt zu bekannten Peers, scheitert aber leicht an SIP-Forking, Weiterleitung oder Retargeting: Der Initiator weiß möglicherweise noch nicht, welches Endgerät antwortet.

RSA-R dreht den Ablauf so, dass das Responder-Zertifikat in-band bereitgestellt werden kann. Diese Eigenschaft ist wertvoll und konkret. Sie erweitert die Menge erreichbarer Szenarien. Sie verändert jedoch nicht automatisch den Schutz vergangener Sitzungen.

Der Initiator kann ein optionales RAND beisteuern. RFC 5197 markiert die Beteiligung beider Seiten deshalb mit einer Bedingung. Weil der Initiator nicht erzwingen kann, dass der Responder den Zufallswert ehrlich einbezieht, entsteht kein echtes PFS. Ein Bericht muss daher sagen: Zertifikat in-band erhalten; Beitrag angeboten; tatsächliche Bindung verifiziert oder nicht; PFS nicht geliefert. Aus mehreren positiven Teilwerten darf kein positives Gesamtsiegel errechnet werden.

PFS ist keine Eigenschaft des Zertifikats

Perfect Forward Secrecy fragt, ob eine spätere Kompromittierung langfristiger Schlüssel frühere Sitzungsschlüssel offenlegt. Ein gültiges Zertifikat beantwortet dagegen, welchem Schlüssel eine Identität zugeordnet wird. Es kann außerdem sein, dass die Zertifikatskette geprüft wurde, der Widerrufsstatus aber nicht in Echtzeit verfügbar war.

PSK und RSA bieten laut RFC 5197 kein PFS. Bei beiden bestimmt der Initiator das Schlüsselmaterial. DH-SIGN bietet gegenseitige Beteiligung und PFS, setzt für breite Skalierung aber eine vertrauenswürdige Zertifikatsinfrastruktur voraus. DH-HMAC erreicht Beteiligung beider Seiten und PFS ohne PKI, beginnt dafür mit einem vorverteilten Geheimnis und ist kein universeller Gruppenmechanismus.

NULL verlässt sich vollständig auf TLS, IPsec oder eine andere untere Schicht. Endet TLS an einem Proxy, kann dieser Proxy den Master Key sehen. Die Aussage transportgeschützt muss deshalb die tatsächlichen Endpunkte enthalten. Der Name des MIKEY-Modus allein kann weder Identität noch Ende-zu-Ende-Schutz tragen.

Ein Modus wird unter Voraussetzungen wahr

Die Auswahlskizze in RFC 5197 beginnt nicht mit einer Rangliste, sondern mit vorhandenem Material. Gibt es einen PSK, ist PSK möglich. Sind zusätzlich PFS und beidseitige Entropie gefordert, kommt DH-HMAC in Betracht. Ist der öffentliche Schlüssel des Responders bekannt, passt RSA. Fehlt die Vorabkenntnis, hilft RSA-R. Fordert die Policy PFS und Beiträge beider Parteien, passt DH-SIGN. Fehlen PSK und Zertifikate, kann NULL nur dann vertretbar sein, wenn die untere Schicht die beabsichtigte Grenze schützt.

Die Reihenfolge zeigt, warum Konfigurationsinventare nicht genügen. Ein System kann sechs Modi unterstützen und in einer konkreten Sitzung doch nur einen ausführen. Der Nachweis muss das gewählte Verfahren mit den in diesem Moment verfügbaren Voraussetzungen verbinden.

Zeit und Scope bleiben eigenständige Dimensionen

MIKEY verwendet Zeitstempel und Message Caching zur Replay-Behandlung. Ohne genügend synchronisierte Uhren kann sie versagen; die Cachegröße soll zur erlaubten Uhrabweichung passen. Zertifikatsprüfung und Replay-Prüfung benötigen deshalb jeweils ihre eigenen Zeitbelege.

RSA-R benötigt außerdem eine Antwort. Bei Early Media kann SRTP den Initiator erreichen, bevor die Antwort den längeren Signalisierungsweg durchlaufen hat. Das Zertifikat ist dann vielleicht unterwegs, der endgültige Schlüssel aber noch nicht verfügbar. Mode gewählt und Key ready brauchen getrennte Zeitstempel.

Schließlich kann ein Crypto Session Bundle mehrere Crypto Sessions mit gemeinsamer TGK und getrennten TEK enthalten. Forking kann Keying-Material auf mehrere Ziele ausdehnen. Nutzen zwei Branches dieselbe TEK und wählen denselben 32-Bit-SSRC, kann ein Two-Time-Pad entstehen. Der Scope jedes abgeleiteten Schlüssels gehört deshalb in denselben Nachweis wie der Modus.

Der minimale Sitzungsnachweis

Erfassen Sie Initiator, erwartete und tatsächliche Responder, Fork- oder Retargeting-Kontext und den ausgeführten Modus. Für Zertifikate gehören Chain, Identitätsbindung, Prüfuhrzeit und Widerrufsfrische dazu. Für PSK und untere Schichten genügen nicht die Geheimnisse selbst, sondern Kennung, Gültigkeit und tatsächliche Vertrauensendpunkte.

Speichern Sie die Beiträge beider Seiten und das explizite PFS-Ergebnis. Binden Sie den Transcript-Hash an CSB, TGK-Kennung, Crypto Sessions und TEK-Scopes. Fügen Sie Zeitquelle, Skew, Cachezustand, Branches, SSRC sowie Antwort-, Installations- und erste erfolgreiche Decrypt-Zeit hinzu.

Das ist keine neue Protokollforderung an RFC 5197. Es ist die betriebliche Konsequenz daraus, dass Implementierung, Auswahl, Authentisierung, Abschluss und nutzbares Medium verschiedene Realitätsschichten sind. RSA-R darf für das Problem gelobt werden, das es löst, ohne ihm ein zweites anzudichten.

Quellen

  1. RFC 5197 als HTML
  2. RFC 5197 als Text
  3. Informationsseite zu RFC 5197
  4. IETF Datatracker: RFC 5197
  5. Historie von RFC 5197
  6. Referenzen von RFC 5197
  7. Errata zu RFC 5197
  8. RFC 3830 — MIKEY
  9. RFC 3711 — SRTP
  10. RFC 4650 — DH-HMAC
  11. RFC 4738 — RSA-R
  12. RFC 4567 — Key Management für SDP und RTSP
  13. RFC 4568 — Security Descriptions
  14. RFC 5027 — Security Preconditions
  15. RFC 4086 — Anforderungen an Zufall
  16. RFC 4082 — TESLA
  17. RFC 4442 — TESLA-Bootstrapping
  18. Heng Lu — Realitätsschichten und symbolische Macht
  19. Heng Lu — minimale Anfangsspezifikation
  20. Heng Lu — Primat des laufenden Codes