Zusammenfassung

  • RFC 1510 verband im September 1993 Kerberos-Realms über realmübergreifende Schlüssel und Ticket-Granting-Tickets. transited führte Zwischen-Realms als ungeordnete Menge; das Client- und das Dienst-Realm standen in anderen Ticketfeldern.
  • Bei einem direkten Ein-Hop-Pfad kann transited deshalb leer sein, obwohl die Authentifizierung eine Realm-Grenze überschreitet. RFC 4120 löste RFC 1510 2005 ab und machte die Prüfung zur ausdrücklichen Aufgabe: Der Anwendungsserver kontrolliert den Pfad selbst oder weist ein realmübergreifendes Ticket ohne KDC-Prüfkennzeichen zurück.

Analyse

Zwei Enden außerhalb der Liste

Ein schematisches Beispiel: Eine Person ist in ALPHA.EXAMPLE registriert und fordert ein Ticket für einen Dateidienst in BETA.EXAMPLE an. Teilen beide Realms den nötigen Schlüssel und liegt kein drittes Realm dazwischen, kann transited leer bleiben. Die Ticketfelder der Endpunkte benennen Client und Dienst; das leere Feld hält den direkten Sprung ohne Zwischen-Realm fest.

transited fasst die Zwischen-Realms knapp zusammen. Die Endpunkte stehen in anderen Feldern; bei einem direkten Sprung bleibt der Mittelteil leer.

RFC 1510 beschreibt ein Realm als Verwaltungsbereich mit eigenem Kerberos-Dienst. Das Realm gehört zum Principal-Namen eines Clients und kann dem empfangenden Dienst bei der Entscheidung helfen, ob er eine Anfrage bedient. Für den Übergang in ein anderes Realm richten Administratoren einen realmübergreifenden Schlüssel ein; für jede Richtung kann ein eigener Schlüssel gelten. Das entfernte Realm registriert den Ticket-Granting-Dienst des anderen als Principal. Sein KDC kann das vom Partner ausgestellte Ticket dann mit dem gemeinsamen Schlüssel entschlüsseln.

Der Client braucht dadurch kein separates Konto in jedem Ziel-Realm. Zuerst erhält er ein Ticket für den Ticket-Granting-Dienst des entfernten Realms, dann verwendet er es, um ein Ticket für die Zielanwendung anzufordern. Der gemeinsame Schlüssel ist die kryptografische Brücke. Ob jemand sie einrichtet und pflegt, ist eine Verwaltungsentscheidung.

Zwischen-Realms als ungeordnete Menge

Ein Pfad kann mehrere Realms durchlaufen. RFC 1510 beschreibt Hierarchien als üblich: Jedes Realm teilt einen Schlüssel mit seinem Eltern-Realm und besitzt andere Schlüssel zu seinen Kindern. So lässt sich ein Pfad bilden, wenn die Endpunkte keinen direkten Schlüssel teilen. Die Spezifikation erlaubt auch alternative Routen, die Zwischen-Realms umgehen, etwa um die Kommunikation effizienter zu machen. Ohne Hierarchie kann eine zusätzliche Datenbank nötig sein.

RFC 1510 speichert die Zwischen-Realms als ungeordnete Menge und komprimiert gebräuchliche Hierarchienamen. Die Reihenfolge steht außerhalb des Feldes; für eine zeitliche Rekonstruktion braucht der Betreiber ein separates Protokoll.

Der Ticket-Granting-Dienst fügt das Realm hinzu, das das empfangene Ticket ausgestellt hat; sein eigenes Realm bleibt außerhalb des Feldes. So kann ein Server seine Teilnahme nicht allein durch Weglassen des eigenen Namens verbergen. Andere Realms kann er weiterhin auslassen; die empfangende Anwendung muss diese Angaben anhand ihrer Vertrauensregeln bewerten.

Im Juli 2005 ersetzte RFC 4120 RFC 1510 und beschrieb die Prüfpflicht genauer. Der Anwendungsserver entscheidet letztlich über Annahme oder Ablehnung der Authentifizierung. Er soll prüfen, ob die beteiligten KDCs vertrauenswürdig genug sind, den genannten Principal zu authentifizieren. Der KDC des Ziel-Realms kann eine realmbezogene Richtlinie anwenden und das Dienstticket mit TRANSITED-POLICY-CHECKED markieren. Hat der KDC nicht geprüft, muss die Anwendung den Pfad selbst kontrollieren oder ein realmübergreifendes Ticket ohne dieses Kennzeichen ablehnen. RFC 4120 warnt zusätzlich: Auch eine Liste vertrauenswürdiger KDCs beweist nichts aus sich heraus; ein nicht vertrauenswürdiger KDC kann sie gefälscht haben.

Die Zuständigkeit verteilt sich auf drei Stellen: Administratoren richten realmübergreifende Schlüssel ein, KDCs stellen Tickets aus und vermerken Prüfungen, und Anwendungen entscheiden, welche Pfade sie akzeptieren. Ein zusätzlicher Schlüssel kann die Route verkürzen und Zugriffe erleichtern; zugleich erweitert er den Kreis von Identitäten, die verbundene Dienste akzeptieren können. Wer den Schlüssel in eine Konfiguration einträgt, genehmigt damit künftige Zugänge; das Netzdiagramm hält den gewählten Pfad fest.

RFC 1510 hielt im September 1993 fest, dass das Protokoll noch geprüft wurde und damals nicht zur Internet-Standardisierung eingereicht war. RFC 4120 kam 2005 auf den Standards Track und formulierte Implementierungspflichten genauer. Es fehlt ein Einsatzprotokoll aus den 1990er-Jahren, das zeigt, welche Anwendungsserver transited prüften; damit ließe sich feststellen, ob diese Kontrolle in laufenden Systemen existierte, während die RFCs den Protokollentwurf dokumentieren.

Quellen