Zusammenfassung

  • RFC 3157 verlangte Vertraulichkeit und Integrität beim Bewegen von Berechtigungsnachweisen, erklärte ein verschlüsseltes Depot aber nicht für vertrauensfrei. Der Server konnte den Schlüssel nicht nutzen und trotzdem Existenz, Version, Herausgabe und Löschung beherrschen.
  • Der SACRED-Rahmen sollte sowohl einen Credential-Server als auch die direkte Übertragung zwischen Geräten tragen. Der erste bündelte dauerhafte Aufbewahrung und Politik, die zweite vermied diese Bündelung um den Preis von Auffindbarkeit, Kompatibilität, Authentisierung und belastbarer Empfangsbestätigung.
  • Upload, Download oder authentisierte Quittung beweisen nur den benannten Vorgang. Sie beweisen weder sichere Ablage am Ziel noch Löschung anderer Kopien, administrative Befugnis, Akzeptanz durch Gegenstellen oder den Erfolg der Anwendung.

Als eine kryptografische Identität länger lebte als ein Rechner

Das frühe Modell war anschaulich, weil mehrere Grenzen zusammenfielen. Ein Nutzer erzeugte ein Schlüsselpaar auf einem Rechner, gab den öffentlichen Teil an eine Zertifizierungsstelle und behielt den privaten Teil auf demselben Gerät. Maschine, Speicherort und Signaturfähigkeit schienen dasselbe Schicksal zu teilen.

Mehrere Geräte lösten diese Übereinstimmung auf. Dieselbe Person wollte E-Mails am Bürorechner und unterwegs am Notebook signieren. Sie mochte Nachrichten auf einem Telefon oder Zweiwege-Pager entschlüsseln. Ein Router konnte ausgetauscht werden, während seine Peers dem alten öffentlichen Schlüssel weiter vertrauten. Alle Gegenstellen nur wegen eines neuen Gehäuses umzukonfigurieren, erzeugte Koordinationskosten jenseits der Kryptografie.

RFC 3157 nannte das Problem Credential Mobility. Berechtigungsnachweise umfassten private Schlüssel, Vertrauensanker, Tickets und private Teile einer Personal Security Environment. S/MIME, IPsec und TLS erschienen als mögliche Abnehmer; das Anforderungsdokument definierte sie nicht neu. Es ging darum, Material so zu bewegen, dass ein anderes Gerät eine bereits etablierte Sicherheitsidentität fortsetzen konnte.

Beim Router war „die Identität verschieben“ eine nützliche, aber gefährlich weite Formulierung. Bewegt wurden kryptografisches Material und die Fähigkeit, bestehende Prüfregeln zu erfüllen. Altgerät, neues Gehäuse, Administrator, Aussteller, Peer-Konfiguration und Verkehr blieben getrennte Objekte. Eine Schlüsselkopie konnte kryptografische Kontinuität erhalten, ohne die Befugnis zur Migration mitzuliefern.

Zwei Architekturen verteilten Macht und Ausfall verschieden

Der SACRED-Rahmen musste eine Serverlösung und eine direkte Übertragung unterstützen. Das war keine ästhetische Wahl zwischen Diagrammen. Jede Architektur bestimmte, wer dauerhaft speicherte, wer eine Zustellung verhindern konnte und welcher Beleg den Vorgang abschloss.

Im Servermodell lud ein Gerät den geschützten Nachweis in ein Depot; ein anderes holte ihn nach beliebiger Zeit ab. Eine Organisation erhielt einen vertrauten Client-Server-Dienst, Speicherung unabhängig vom Überleben des Ursprungsgeräts und einen Ort für einheitliche Regeln.

Der Komfort konzentrierte Abhängigkeit. Der Server musste gefunden oder konfiguriert, geschützt, verfügbar gehalten und wiederherstellbar sein. Ein ausschließlich mit Chiffraten gefülltes Depot blieb ein lohnendes Ziel für Kopie, Zerstörung oder Blockade. Gerade wenn ein Ersatzgerät den Nachweis benötigte, konnte der zentrale Dienst unerreichbar sein.

Direkte Übertragung beseitigte die dauerhafte Ablage beim Vermittler. Knoten, die Pakete weiterleiteten, wurden dadurch nicht zu Credential-Servern. Die Kosten wanderten zu den Endpunkten: Geräte mussten einander finden, gleichzeitig erreichbar sein, kompatible Transporte und Authentisierungsverfahren besitzen und Format- oder Fähigkeitsunterschiede bewältigen. War Zustellung wichtig, brauchte der Sender eine verlässliche Quittung.

Das Dokument erklärte keine Architektur zum universellen Sieger. Die sichtbare Trennung verhinderte, dass der Serverkomfort seine Verweigerungsmacht oder die Dezentralität der Direktübertragung ihre Endpunktkomplexität verdeckte.

Chiffrat beseitigte keine operative Herrschaft

Eine allgemeine Anforderung war eng gefasst: Das Protokoll durfte nicht verlangen, dass Berechtigungsnachweise außerhalb der Endgeräte des Nutzers im Klartext erscheinen. Der Server konnte eine geschützte Hülle speichern oder weitergeben, ohne den privaten Schlüssel zu öffnen.

Das war eine Vertraulichkeitsgrenze, kein Beweis der Machtlosigkeit. Der Betreiber konnte weiterhin bestimmen, ob ein Objekt existierte, auffindbar war, welche Version zurückkam, ob ein Upload ersetzte und ob eine Löschung die Serverkopie entfernte. Jemand konnte unfähig sein, mit dem Schlüssel zu signieren, und zugleich die verfügbare Kopie vernichten.

Auch „Credential löschen“ hatte einen begrenzten Geltungsbereich. Das Entfernen eines Depotdatensatzes bewies nicht, dass Kopien auf Geräten, in Sicherungen, Caches oder Exporten verschwanden. Die äußere Identität konnte fortbestehen: Peers hielten den öffentlichen Schlüssel, anderswo überlebte vielleicht eine private Kopie. Bewiesen war die Veränderung eines bestimmten Depots.

Verfügbarkeit war ebenso von Offenlegung getrennt. RFC 3157 bezeichnete Credential-Server als bedeutende Ziele für Denial-of-Service. Die Unlesbarkeit des Schlüssels garantierte nicht seine rechtzeitige Abrufbarkeit. Vertrauliches, aber unerreichbares Material konnte signierte Mail, einen Routertausch oder jeden anderen Kontinuitätsprozess stoppen.

Diese Grenze ist die dauerhafteste Einsicht des Dokuments. Kryptografie beschränkt, wer geschütztes Material erfährt oder verwendet. Sie beschränkt nicht automatisch, wer es zurückhält, ersetzt, auf eine alte Version setzt, löscht oder nicht ausliefert.

Das Verb bestimmte die Grenze von Befugnis und Quittung

Ein allgemeiner „Synchronisieren“-Vorgang reichte nicht. RFC 3157 verlangte Funktionen zum Auflisten, Hinzufügen und Löschen von Nachweisen sowie zum Ändern der Authentisierungsinformationen. Selbstregistrierung war erforderlich; administrative Masseninitialisierung durfte möglich sein.

Jedes Verb öffnete eine andere Befugnisfläche. Auflisten zeigte Bestand, nicht das Geheimnis. Herunterladen gab ein Objekt an ein Gerät. Hochladen erzeugte oder ersetzte Serverzustand. Löschen entfernte serverseitigen Zustand. Passwortänderung verschob die künftige Authentisierungsgrenze. Registrierung begründete eine Kontobeziehung. Ein erfolgreicher Vorgang berechtigte nicht zum nächsten.

Nutzerauthentisierung vor dem Download beantwortete, wer im Kontomodell Zugriff verlangte. Serverauthentisierung half zu verhindern, dass der Client Geheimnisse an einen Hochstapler gab oder Material von einer falschen Quelle annahm. Credential-Authentisierung konnte Austausch oder Beschädigung erkennen.

Keine dieser Prüfungen belegte die Vertrauenswürdigkeit des Zielgeräts. Ein korrekter Nutzer konnte sich über kompromittierte Software anmelden. Ein echter Server konnte eine alte, aber gültige Hülle liefern. Ein authentischer Nachweis konnte später für eine Handlung dienen, die der Mensch nie genehmigt hatte. Identität, Objektintegrität, Gerätevertrauen und Handlungsbefugnis waren unterschiedliche Entscheidungen.

RFC 3767 machte beim späteren Serverprotokoll eine weitere Trennung sichtbar: Ein Kontopasswort authentisierte den Dienstzugriff, ein Credential-Passwort schützte private Teile des heruntergeladenen Objekts. Beides einer einzigen Prüfung zuzuschreiben, hätte ihren Aussagebereich unzulässig erweitert.

Formatopazität verringerte Abstimmung, nicht Beweislast

RFC 3157 forderte, Typ und inneres Format für die Übertragungspartner undurchsichtig zu halten. Das Protokoll sollte nicht jeden privaten Schlüssel, jedes Ticket oder jeden Container verstehen müssen. Auch unterschiedliche Nutzer-Authentisierungen und Transporte sollten möglich sein.

Das bildete eine minimale gemeinsame Oberfläche. Zwei Systeme konnten eine geschützte Hülle bewegen, ohne die interne Darstellung des anderen zu übernehmen. Ein begrenztes Gerät musste nicht alle Formate seiner Gegenstellen implementieren.

Die Opazität verlangte zugleich präzisere Ergebnisdeutung. Wenn der Server den Inhalt nicht interpretierte, bewies „Upload erfolgreich“ den Empfang bestimmter Bytes, nicht den richtigen Schlüssel, ein funktionierendes Passwort, erfolgreichen Import oder spätere Nutzbarkeit. Kennung, Version, Fingerabdruck und Integrität mussten jeden Schritt überstehen.

Eine „aktuelle Version“ durfte keine stillschweigende Annahme sein. Ein Depot konnte normal antworten und dennoch eine ältere Hülle liefern. Ein Rollback musste das Geheimnis nicht offenlegen, um widerrufene Rechte, abgelaufene Schlüssel oder alte Politik zurückzubringen. Zeitfolge und Objektidentität waren Teil des Nachweises.

Ankunft, Speicherung und Wirkung waren drei Ereignisse

Bei direkter Übertragung musste der Empfänger den Sender authentisieren und der Sender eine Empfangsbestätigung erhalten. Die Quittung schloss eine wichtige Frage: Der vorgesehene Endpunkt, nicht irgendein Vermittler, hatte den Vorgang im Sinne des Protokolls bestätigt.

Ihre Bedeutung blieb begrenzt. Sie mochte zeigen, dass bestimmte Bytes zu einem Zeitpunkt einen Prozess erreichten. Sie zeigte nicht, dass das Betriebssystem sicher speicherte, der Import endete, temporärer Speicher gelöscht wurde oder der Nutzer das Objekt später öffnen konnte.

Auch das äußere Ergebnis blieb offen. Beim Router reichte die Kette über Schlüsselimport, Identitätspräsentation, Peer-Akzeptanz und wiederkehrenden Verkehr. Bei Mail reichte sie bis zu Signatur oder Entschlüsselung und der Akzeptanz durch Empfänger oder Dienst. Transport war ein Zustandswechsel, nicht das Endergebnis.

Diese Trennung schützte vor falschem Löschbeweis. Löschte die Quelle nach einer zu schwachen Quittung und der Zielimport scheiterte, wurde Mobilität zum Verlust. Löschte sie nie, entstanden womöglich unbekannte Kopien. Die Quellenpolitik hing vom ausdrücklich belegten Umfang der Quittung ab.

Das Audit konnte zum zweiten Leck werden

RFC 3157 verlangte die Protokollierung sicherheitsrelevanter Ereignisse, besonders auf Servern. Zeitpunkt, Konto, Vorgang und Ergebnis halfen, Versuch und Abschluss, Nutzlöschung und Depotfehler, gewöhnliche Störung und Angriff zu unterscheiden.

Zugleich warnte das Dokument davor, über die Prüfung das geschützte Geheimnis einzusammeln. Ein Nutzer konnte versehentlich sein Passwort in das Feld für den Namen schreiben. Kopierte das System die Roheingabe, landete das Geheimnis im am weitesten replizierten und zugänglichen Teil des Vorgangs.

„Alles loggen“ löste die Spannung nicht. Eine dauerhafte Quittung brauchte genug Identitäts- und Vorgangskontext zur Untersuchung, musste aber Passwörter, private Schlüssel und wiederverwendbare Geheimnisse ausschließen. Die Logs selbst verlangten Zugriffsschutz, Integrität, Aufbewahrungsregeln und verlässliche Zeit.

Ein Eintrag „Download erfolgreich“ sagte allein nicht, welches Objekt welche Speicherfläche erreichte. Eine vollständige Untersuchung verband ihn mit Fingerabdruck, Protokollsitzung, Zielgerät, lokalem Import, späterer Verwendung und Anwendungsergebnis.

Hardware-Einschluss beantwortete eine andere Frage

Der Anhang betrachtete Chipkarten und andere Hardware-Token. Blieb der Nachweis in tragbarer Hardware, konnte der Nutzer ihn zwischen kompatiblen Lesern mitnehmen, ohne privates Material zwischen Hosts zu kopieren. Das bot in manchen Umgebungen eine stärkere Einschlussgrenze.

Es war kein allgemeiner Ersatz. Nicht jedes Gerät besaß einen Leser; Kosten, Kompatibilität, Defekt und Wiederherstellung blieben. SACRED-artige Protokolle konnten Hardware sogar ergänzen, indem sie Nachweise auf einem Token aktualisierten, ohne ihn einem Administrator physisch zurückzugeben.

Darum beschränkte RFC 3157 die Hauptanforderungen auf Software-Nachweise und erkannte deren andere Sicherheitslage an. Die ehrliche Gegenüberstellung lautete nicht „Hardware sicher, Software unsicher“, sondern: Welches Material verlässt welche Grenze, welche Geräte können teilnehmen, wer kann Kontinuität unterbrechen und wie gelingt Erholung?

Das Dokument belegte weder die Sicherheit einer Karte noch die eines Telefons, Pagers oder Arbeitsplatzes. Es beschrieb die Struktur, die Lösungen ohne ausreichenden physischen Einschluss bewältigen mussten.

Das spätere Protokoll wählte nur einen Pfad

RFC 3760 beschrieb später den abstrakten Rahmen; RFC 3767 definierte ein Credential-Server-Protokoll mit XML-Nachrichten und BEEP-Profil. TLS und/oder DIGEST-MD5 trugen Schutz und Authentisierung, während gewöhnlicher Abruf und optionale Kontoverwaltung getrennt wurden.

Diese Linie zeigt Spezifikationsarbeit vom Problem über den Rahmen zum konkreten Protokoll. Sie zeigt nicht, dass alle Anforderungen von RFC 3157 ausgerollt wurden, direkte Übertragung verbreitet war oder ein bestimmtes Produkt Nachweise korrekt schützte.

Die Sorge von RFC 3767 um Offline-Wörterbuchangriffe verdeutlicht erneut die Grenze. Ein Protokoll kann einem Beobachter nützliches Material zur Passwortprüfung vorenthalten und weiterhin von Passwortqualität, Endpunktsoftware, Serververfügbarkeit und korrekter Verschlüsselung abhängen. Widerstand gegen einen Angriff ist keine allgemeine Kontosicherheit.

Der historische Wert von RFC 3157 liegt in den Gleichsetzungen, die es verweigerte. Transportgeheimnis, Depotmacht, dauerhafte Verfügbarkeit, Geräteauthentisierung, Quittung, Speicherung, Identitätskontinuität und spätere Nutzung waren verbunden, aber niemals Synonyme.

Bewegliche Nachweise vergrößerten die Beweisfläche

Das Ein-Gerät-Modell konzentrierte Risiko und vereinfachte den Ablauf. Mobilität verbesserte Erholung und Komfort, fügte aber Übergänge hinzu. Upload, Depotmutation, Download, direkte Übergabe, Import und Nutzung waren getrennte Stellen, an denen Identität kopiert, zurückgehalten, ersetzt oder überinterpretiert werden konnte.

Ein belastbares Audit beginnt bei Aussteller und Fingerabdruck der geschützten Hülle. Es nennt die Architektur, zeichnet Nutzer-, Server- und Geräteauthentisierung getrennt auf, benennt den Vorgang, bewahrt Version und Integrität, beobachtet Depotzustand und Verfügbarkeit, identifiziert Ziel und Vertrauensannahmen und folgt dem Nachweis bis zum abhängigen Protokoll und Dienstergebnis.

Akzeptierten Router-Peers den alten Schlüssel und kehrte der Verkehr zurück, war mehr als ein Download belegt. Lag der Schlüssel am Ziel und die Peers lehnten ihn ab, war Kontinuität nicht wiederhergestellt. Akzeptierten sie ihn nach einer von einem Unbefugten ausgelösten Migration, hatte kryptografische Kontinuität keine administrative Befugnis geschaffen.

RFC 3157 bleibt nicht nur wichtig, weil Schlüssel reisen konnten. Es zeigte, dass Schutz während der Reise die Institutionen und Maschinen nicht beseitigte, die Ankunft, Fortbestand und Wirkung beherrschten. Der Server brauchte keinen Klartext, um mächtig zu bleiben.

Quellen