Zusammenfassung

  • RFC 3652 trennte einen festen, 20 Oktette langen Message Envelope für Zustellung und Wiederzusammensetzung von einem 24-Oktett-Header und einem operationsspezifischen Body. Die digitale Signatur in der Message Credential umfasste den Envelope nicht, wohl aber Header und Body.
  • Die Credential konnte eine Signatur des Absenders oder einen auf einem zuvor eingerichteten Sitzungsschlüssel beruhenden Nachrichtenauthentifizierungscode (MAC) enthalten. Diese Grenze beschreibt den Integritätsschutzumfang des Protokolls – keinen dokumentierten Angriff, Implementierungsfehler oder Ausschluss von Schutz auf tieferen Schichten.

Eine Nachricht, unterschiedliche Vertrauensflächen

2003 musste die Handle-Protokollspezifikation mehr regeln als eine Abfrage. Der Client sollte den zuständigen Handle-Server finden, eine Auflösung oder Verwaltung anfragen und die Antwort verstehen können. Zugleich mussten Nachrichten über Transportwege funktionieren, die Daten unterschiedlich darstellen. RFC 3652 v2.1 ordnete diese Aufgaben in vier angrenzende Teile: Envelope, Header, Body und Credential. RFC 3652

Der Envelope war immer vorhanden und genau 20 Oktette lang. Die RFC beschreibt ihn als Umschlag für die Zustellung, nicht als Anwendungsinformation. Zu seinen Feldern gehörten Protokollversion und Nachrichtenflags, eine Sitzungskennung, eine Anforderungskennung, eine Sequenznummer und die Nachrichtenlänge. Der obligatorische Header war 24 Oktette lang und enthielt gemeinsame Felder wie Operations- und Antwortcode. Der Body trug operationsspezifische Daten und durfte leer sein. RFC 3652

Die Vertrauensgrenze entsprach nicht der Paketgrenze. RFC 3652 legt ausdrücklich fest, dass die digitale Signatur in der Message Credential den Inhalt des Envelope nicht schützte, wohl aber Header und Body. Eine nicht leere Credential konnte die digitale Signatur des Absenders oder einen Einweg-MAC auf Basis eines bereits eingerichteten Sitzungsschlüssels enthalten. Die RFC nennt damit Nachrichtenauthentifizierung und Integritätsprüfung nach der Übertragung als mögliche Zwecke. Ein MAC beruht auf einem gemeinsamen Geheimnis; eine digitale Signatur verwendet ein anderes Schlüsselmodell. RFC 3652 RFC 2104

Diese Trennung passte zur Aufgabe des Envelope. Ein Handle-Client konnte UDP-Datagramme oder einen TCP-Bytestrom verwenden. RFC 3652 begrenzte UDP-übertragene Nachrichten auf 512 Oktette, ohne IP- und UDP-Header. Längere Nachrichten mussten fragmentiert werden; jedes Fragment trug seine Sequenznummer im Envelope, damit der Empfänger es wieder zusammensetzen konnte. TCP lieferte zwar einen Bytestrom, aber keine Handle-Nachrichtengrenzen. Auch dort konnte das Protokoll größere Nachrichten fragmentieren und wieder zusammensetzen. RFC 3652 RFC 768 RFC 793

Header und Body beschrieben dagegen, was Client und Server taten. Der Operationscode forderte eine Art Handle-Vorgang an; der Antwortcode meldete Erfolg, fehlenden Wert, Dienstverweis, Autorisierungsfehler oder erforderliche Authentifizierung. Das Protokoll folgte einem separat definierten Namens- und Datenmodell, während RFC 3650 die Gesamtarchitektur des Dienstes beschrieb. Der geschützte semantische Inhalt begann somit hinter dem Zustellumschlag: Ein Fragment wieder zusammenzusetzen war nicht dasselbe wie die darin enthaltene Operation zu autorisieren. RFC 3652 RFC 3650 RFC 3651

Authentifizierung war keine Autorisierung

RFC 3652 trennte auch den Nachweis des Clients von der Berechtigungsentscheidung des Servers. Bei administrativen Vorgängen konnte der Server eine Challenge senden; der Client antwortete mit dem Nachweis, den passenden privaten oder gemeinsamen geheimen Schlüssel zu besitzen. Selbst nach erfolgreicher Prüfung musste der Server noch feststellen, ob die Administratorrechte für die angeforderte Operation ausreichten. Eine bestandene Challenge war keine Genehmigung, einen Handle zu ändern. Sitzungen konnten außerdem Zustand und Schlüssel für mehrere Vorgänge teilen. RFC 3652

RFC 3552 unterscheidet Datenintegrität, Gegenstellenauthentifizierung, Vertraulichkeit und Systemsicherheit als verschiedene Ziele; Signatur oder MAC liefern nicht automatisch alle davon. RFC 3652 behandelt in seinen Sicherheitsüberlegungen Server-Signaturen und Client-Authentifizierung, aber seine Formatdefinition ist enger: Die Credential umfasst Header und Body, nicht den Zustellumschlag. Daraus folgt nicht, dass eine Nachricht in einem realen Einsatz verändert wurde. Ein Kanal auf einer tieferen Schicht kann zusätzliche Schutzmechanismen bieten; die RFC ist eine Spezifikation, kein Vorfallsbericht. RFC 3552 RFC 3652

Die Handle-Credential ist auch nicht mit dem X.509-Signaturprofil gleichzusetzen. RFC 3279 legt Algorithmenkennungen und Kodierungen für Zertifikate und Sperrlisten dieses PKI-Profils fest. Die RFC erweitert weder den von RFC 3652 signierten Bytebereich noch macht sie den Envelope zu authentifiziertem Inhalt. Kryptografische Begriffe allein reichen nicht: Es muss klar sein, welches Objekt geschützt wird. RFC 3279 RFC 3652

RFC 3652 ist als Informational eingestuft; die IESG-Notiz hält fest, dass die Diskussionen keinen IETF-Konsens über das Handle System oder dessen Einordnung in die IETF-Kennungsarchitektur ergeben hatten. Das Dokument beschreibt ein vorgeschlagenes Protokoll, nicht dessen universelle Einführung. Die begrenztere Lehre lautet: Framing, Wiederzusammensetzung und Authentifizierung können unterschiedlichen Regeln folgen. Jede Integritätsbehauptung sollte daher nennen, welche Bytes die Credential tatsächlich umfasst. RFC 3652

Quellen