Zusammenfassung

  • RFC 1507 beschrieb, wie eine globale Benutzeridentität zwischen Rechnern wiedererkannt werden sollte, ohne die lokale Konto- und Zugriffsverwaltung abzuschaffen.
  • DASS band Namen an öffentliche Schlüssel, ordnete Zertifizierungsstellen dem X.500-Namensbaum zu und konnte Benutzer- und Rechnernachweise gemeinsam übertragen.
  • Der Entwurf blieb als Experimental gekennzeichnet. Die Spezifikation belegt eine technische Absicht, aber keine Verbreitung im laufenden Internet.

Ein Konto war eine lokale Antwort

Der RFC 1507 beginnt mit einer administrativen Reibung: Wer auf zehn Rechnern ein Konto besitzt, erscheint einem entfernten Dienst zunächst als zehn verschiedene Konten. Jede Ressource muss wissen, welche davon zusammengehören. Ein elfter Rechner erzeugt eine weitere Pflegeaufgabe. Wird der Benutzer über einen anderen Rechner angemeldet, kann der entfernte Dienst zudem eine andere lokale Kennung sehen.

Der im September 1993 veröffentlichte Distributed Authentication Security Service (DASS) wollte diese Darstellung vereinheitlichen. Ein Benutzer sollte einen Namen aus einem globalen Namensraum erhalten, den jeder Knoten des Netzes erkennen kann. Der Zugriff auf eine Ressource konnte trotzdem davon abhängen, von welchem Rechner aus der Benutzer handelte. Das Netzwerkprinzipal sollte gleich bleiben; die Zugriffsregel durfte enger sein.

DASS plante keinen abrupten Ersatz der lokalen Konten. Betriebssysteme sollten weiterhin Benutzer auf lokale Konten abbilden. Als Übergang nennt das RFC Regeln ähnlich zu .rhosts: Ein lokales Konto könnte einen globalen DASS-Namen zulassen, ohne alle Zwischenrechner auflisten zu müssen, die der Benutzer gerade verwendet. Die globale Identität sollte den Weg zur Maschine überstehen, die lokale Entscheidung aber nicht übernehmen.

Der Name musste zu einem Schlüssel führen

Damit der Name in einer entfernten Anfrage belastbar war, verwendete DASS öffentliche Schlüssel und Zertifikate. Eine Zertifizierungsstelle (CA) bestätigte die Zuordnung zwischen einem Namen und einem öffentlichen Schlüssel. Der jeweilige Prinzipal konnte mit dem privaten Schlüssel signieren, ohne dieses Geheimnis bei jeder Verbindung über das Netz zu senden.

Das Modell schloss auch Rechner ein. Benutzer und Knoten konnten eigene Nachweise besitzen und dieselbe Anfrage mit jeweils ihrem Geheimnis signieren. Der empfangende Server konnte damit sowohl den Benutzer als auch die Maschine prüfen, die den Zugriff vermittelte. Eine Ressource hätte einen Benutzer beispielsweise nur von einem bestimmten Rechner aus zulassen können. Ein einzelnes lokales Konto hätte diese beiden Fragen nicht getrennt beantworten müssen.

Die CA-Hierarchie folgte dem X.500-Namensbaum. Eine CA war für die Prinzipale in ihrem Verzeichnis zuständig; Zertifikate zwischen Eltern- und Kindverzeichnissen verbanden die Ebenen. Für weit voneinander entfernte Bereiche konnten Kreuz-Zertifikate helfen. So sollte kein einzelner Betreiber sämtliche öffentlichen Schlüssel kennen oder in jeder Organisation die direkte Wurzel des Vertrauens sein müssen.

Der Baum konnte den Schaden einer kompromittierten CA begrenzen, nicht ausschließen. Eine CA konnte Prinzipale in ihrem Zuständigkeitsbereich vortäuschen. Eine tiefe Kompromittierung betraf typischerweise einen begrenzteren Ast; eine weiter oben liegende CA hatte entsprechend breitere Auswirkungen. Diese Grenze war an die Verwaltungsstruktur der Namen gebunden. Sie funktionierte nur, wenn die Zuständigkeiten der Verzeichnisse und die Ausstellung der Zertifikate verlässlich waren.

Der Namensbaum sollte Änderungen verteilen

Ein globaler Name ist nur nützlich, wenn entfernte Systeme das passende Zertifikat finden und erkennen können, ob es noch gilt. DASS setzte dafür auf einen verteilten Namensdienst. Der RFC nennt zwei Wege, Zertifikate zu widerrufen.

Der erste Weg war die normale Erneuerung: Zertifikate liefen ab, und eine CA stellte rechtzeitig neue aus. Für den üblichen Betrieb erwartete DASS eine Gültigkeit von ungefähr einem Jahr. Erneuerungen konnten Monate auseinanderliegen, damit der Aufwand für CA und Benutzer nicht zu groß wurde. Bei einem kompromittierten Schlüssel war das kein schneller Rückruf; ein altes Zertifikat konnte bis zum Ablauf weiter akzeptiert werden.

Der zweite Weg war eine Positivliste im Namensdienst. Ein Server sollte nur Zertifikate akzeptieren, die dort noch eingetragen waren. Das konnte eine schnellere Rücknahme ermöglichen, hing aber von der Verteilung und den Zwischenspeichern des Verzeichnisses ab. Das RFC beschreibt den Zielkonflikt ausdrücklich: Die Authentifizierung war nur so verfügbar wie der Namensdienst; die Sicherheit des Widerrufs hing ebenso von dessen Sicherheit ab. X.509-Sperrlisten unterstützte DASS in dieser Version noch nicht.

Auch Zeit war Teil der Prüfung. DASS setzte Zeitstempel gegen Replay ein, statt zusätzliche Nachrichten für ein Challenge-Response-Verfahren auszutauschen. Der Empfänger musste alte Nachrichten ablehnen und bereits gesehene Authentifikatoren innerhalb des Zeitfensters speichern. Für die Zertifikatsgültigkeit genügten mehrere Stunden Genauigkeit; die Replay-Prüfung erforderte eine monotone, im Netz auf Minuten synchronisierte Uhr. Eine große Abweichung konnte gültige Anfragen zurückweisen, ein Rückstellen der Uhr eine alte Nachricht wieder akzeptabel machen.

Delegation machte aus dem Namen eine Arbeitsberechtigung

Wenn ein Prozess einen zweiten Dienst aufrufen musste, konnte DASS dem entfernten Prozess eine delegierte Benutzerberechtigung geben. Das Betriebssystem sollte die Credentials den Prozessen zuordnen, die im Auftrag des Benutzers liefen. Das ersparte eine erneute Passwortabfrage bei jedem Dienstwechsel und machte den globalen Namen für verteilte Arbeit praktisch nutzbar.

Die Delegation war jedoch keine fein zugeschnittene Erlaubnis. Das RFC sagte, sie könne zeitlich begrenzt werden, nicht aber auf die einzelnen Rechte, die ein Dienst für eine bestimmte Aufgabe benötigte. Während die Credentials gültig waren, konnte der Dienst als Benutzer handeln. Eine engere Delegation nannte der Text als mögliche spätere Erweiterung.

Der Login-Knoten blieb besonders empfindlich. Vor dem Einsatz intelligenter Karten konnte das Passwort beim ersten Login abgehört werden. DASS wollte verhindern, dass das Passwort über diesen ersten Knoten hinaus durch das Netz wanderte. Eine Smartcard könnte den privaten Schlüssel halten und zu Beginn der Sitzung eine Signatur erzeugen. Auch das beschreibt ein Designziel, nicht die tatsächliche Ausstattung von Internet-Rechnern.

Status und Reichweite der Quelle

Der RFC bezeichnet DASS als Experimental und sagt ausdrücklich, dass er keinen Internet-Standard festlegt. Ein Anhang beschreibt, wie DASS das Generic Security Service API unterstützen könnte. RFC 1508 definiert diese allgemeine, mechanismusunabhängige Schnittstelle; RFC 1509 legt die C-Bindings fest. Der RFC 1510 dokumentiert zeitgleich Kerberos V5 mit einem vertrauenswürdigen Schlüsselverteilungsdienst. RFC 1704 stellt später mehrere Authentifizierungsmechanismen nebeneinander.

Diese Dokumente zeigen die Vielfalt der Entwürfe Anfang der 1990er Jahre. Sie sagen nicht, wie viele Betreiber DASS einsetzten, ob es in großem Maßstab lief oder warum es sich nicht durchgesetzt haben könnte. Ein experimenteller RFC ist eine Normstatusangabe, keine Messung von Software in Betrieb.

DASS' eigentliche Verschiebung lag zwischen lokalen und globalen Namen: Ein Benutzer sollte nicht an den Rechner gebunden bleiben, während jede Ressource trotzdem selbst über den Zugriff entschied. Dafür brauchte das System eine Kette aus CA, Namensdienst, Betriebssystem, Prozess und lokalem Konto. Sie machte Identität portabel, verteilte aber auch Verantwortung für Zertifikat, Widerruf und Ausführung auf mehrere Stellen.

Quellen