Zusammenfassung

  • Nach Annahme des IRIS-Profils und Erzeugung des BEEP-Kanals nannte RFC 3983 den Kanal bereit. Das war eine Aussage über Nachrichtenfähigkeit für angekündigte Registertypen, nicht über Server- oder Nutzeridentität.
  • Serverauthentisierung konnte typspezifisch, nach dem TLS-Grundverfahren oder ausdrücklich gar nicht stattfinden. Verschlüsselung, Nutzerauthentisierung, Abfrageberechtigung und Vertrauen in ein Verweisziel blieben eigenständige Nachweise.

Jede Spezifikation eines Registertyps musste zwei Entscheidungen offenlegen: welches Nachrichtenmuster sie auf BEEP verwendete und wie sie den Server authentisierte. Für die zweite Entscheidung gab es drei Wege — ein eigenes Verfahren, das Grundverfahren aus RFC 3983 oder die ausdrückliche Erklärung, überhaupt keine Serverauthentisierung zu verwenden. Schon diese Auswahl widerlegt die bequeme Annahme, ein erfolgreich ausgehandelter Kanal habe die Gegenseite automatisch identifiziert.

RFC 3983 erschien im Januar 2005 als Standards-Track-Abbildung des Internet Registry Information Service auf das Blocks Extensible Exchange Protocol. Statusseite, Errata und Datatracker-Akte belegen den Dokumentzustand, nicht Verbreitung oder einen heute laufenden Dienst.

BEEP brachte Framing, Authentisierung, Verbindungsverwaltung und Aushandlung sowie vorhandene Werkzeuge mit. Ein eigenes IRIS-Transportprotokoll hätte ähnliche Funktionen neu bauen müssen. HTTP erschien den Autoren wegen möglicher Verwechslung mit Web-Anwendungen und uneinheitlicher TLS-Praxis ungeeignet; direktes TCP besaß nicht die Aushandlung für einen verweisenden Client, der Server mit unterschiedlichen Parametern besuchte. Diese Begründung ist kein gemessener Leistungsvergleich.

Die Profil-URI verband die Version des IRIS-Schemas mit der URN des Registertyps. Bei der Kanalerzeugung konnten mehrere profile-Elemente angeboten und Versionen für die bedienten Typen ausgehandelt werden. Nach Annahme des Profils und Erzeugung des Kanals galt er als bereit für IRIS-Nachrichten. Der Server musste Abfragen aller von ihm angekündigten Registertypen auf einem solchen Kanal honorieren.

Honorieren war nicht gleichbedeutend mit Datenausgabe. Im Standardmuster sandte der Client eine gültige IRIS-XML-Instanz als BEEP MSG; der Server antwortete mit IRIS XML in RPY, während ERR BEEP-Fehler trug. Andere BEEP-kompatible Muster waren zulässig, doch für lookupEntity musste das Standardmuster funktionieren. Der IRIS-Kern und sein Status regelten darüber die registerspezifischen Ablehnungen und nicht unterstützten Abfragen. Bereitschaft ermöglichte den Austausch, nicht dessen Erfolg.

Bei Verwendung des TLS-Tuning-Profils benötigte die Serveridentität eine eigene Konvention. Ohne typspezifische Festlegung griff das Grundverfahren. Der Client übermittelte die gewünschte Authority in BEEPs serverName. Der Server legte ein X.509-Zertifikat mit dieser Authority vor. Danach musste der Client sowohl die kryptographische TLS-Prüfung durchführen als auch den Zertifikatsnamen in festgelegter Reihenfolge gegen die Authority abgleichen.

Ein kryptographisch gültiges Zertifikat kann für einen anderen Namen gelten. Ein passender Name in einer ungeprüften Bescheinigung ist ebenfalls kein Identitätsbeleg. Erst Vertrauenskette und Namensbindung beantworteten gemeinsam, ob die präsentierte Identität die angefragte Authority vertrat.

Nutzeridentität war wiederum nicht aus dem Servernachweis ableitbar. RFC 3983 nannte SASL DIGEST-MD5 und OTP zur Nutzerauthentisierung ohne Sitzungsverschlüsselung. Sie unterschied TLS nur zur Verschlüsselung von TLS mit Client-Zertifikaten für Verschlüsselung plus Nutzerauthentisierung. Anonymer Zugang konnte ohne Authentisierungs-Tuning oder mit SASL ANONYMOUS erfolgen. Verschlüsselt, serverauthentisiert, nutzerauthentisiert und für ein Ergebnis berechtigt waren keine aufeinanderfolgenden Synonyme.

Diese Komposition stammte aus BEEP. RFC 3080, Status, Errata und Datatracker definierten Profile, Kanäle, Nachrichten und Tuning. RFC 3081 und die Statusseite bildeten BEEP auf TCP ab. Ein Tuning-Schritt konnte eine Sicherheitseigenschaft ändern, ohne die anderen zu bescheinigen.

Die zeitgenössischen Grundlagen begrenzen die Aussage. RFC 2246 und ihr Status beschrieben TLS 1.0. RFC 2222 und ihr Status lieferten den damaligen SASL-Rahmen. RFC 2817 samt Status und RFC 2818 samt Status dokumentierten die in RFC 3983 besprochenen HTTP/TLS-Wege. Vorhandene Mechanismen beweisen keine korrekte Nutzung in einer konkreten Sitzung.

Verweise machten den Unterschied zwischen Geheimhaltung und Vertrauen praktisch. Ein IRIS-Client konnte regulär zu einem anderen Server geschickt werden. RFC 3983 warnte davor, diesem ungeprüft Zugangsdaten zu geben, riet von SASL PLAIN ab und verbot PLAIN vor der Verschlüsselung der TCP-Sitzung. Verschlüsselung schützte das Geheimnis unterwegs; sie berechtigte den Empfänger nicht dazu.

Später ergänzten RFC 4992 und ihr Statusnachweis den XPC-Transport über TCP und aktualisierten den Kern. Daraus folgt Austauschbarkeit, nicht eine gemessene Ursache für Einführung oder Ablösung.

Im IANA-Verzeichnis der URI-Schemata steht weiterhin iris.beep; das IANA-Verzeichnis der BEEP-Parameter führt Profil- und Tuning-Namensräume. Solche Einträge beweisen Registrierung, nicht Kanalzustand, Identität, Berechtigung oder Ergebnis.

RFC 3983 hinterließ damit eine nützliche Grenze: Ein Kanal durfte bereit heißen, sobald er die ausgehandelten Nachrichten tragen konnte. Wer daraus Vertrauen und Erlaubnis ableitet, macht aus einer Transportfähigkeit einen Identitätsbescheid, den die Spezifikation ausdrücklich nicht erteilte.

Sources