Zusammenfassung

  • RFC 5178 lässt einen Client service [AT] domain [AT] hostname authentisieren, wobei [AT] für das wörtliche ASCII-At-Zeichen der RFC-Syntax steht. So weist ein entdeckter Host seine Befugnis für einen bestimmten Domain-Dienst nach und nicht nur seine eigene Identität.
  • RFC 5179 übernimmt die drei Teile in ein Kerberos-Principal, verlangt aber, den Realm aus dem Hostnamen statt aus dem Domain-Feld der Eingabe abzuleiten. Dienstmandat und Authentifizierungszuständigkeit bleiben getrennte Entscheidungen.

Ein Name kann zwei Behauptungen enthalten, ohne dass dieselbe Stelle beide entscheiden darf. Die eine Behauptung lautet: Dieser Host soll einen Dienst für eine bestimmte Domain erbringen. Die andere lautet: Dieser Kerberos-Realm ist für die Authentifizierung des Hosts zuständig.

Würde das Domain-Feld der ersten Behauptung den Realm der zweiten frei bestimmen, könnte die Eingabe ihre eigene Prüfinstanz mitbringen. RFC 5179 zieht deshalb eine unscheinbare, aber entscheidende Grenze.

Entdeckung kann wahrheitsgemäß falsch enden

RFC 5178 beginnt früher in der Kette. Ein Client sucht etwa einen LDAP- oder NFS-Dienst über DNS SRV. Ohne DNSSEC kann die Antwort auf einen falschen Server zeigen. Dieser Server muss keine fremde Hostidentität stehlen. Besitzt er ein gültiges Credential für sich selbst, kann host-basierte Authentisierung erfolgreich und dennoch für die beabsichtigte Ressource unzureichend sein.

Der Client hat bestätigt, dass der Server der Host aus der manipulierten Antwort ist. Er hat nicht bestätigt, dass der Server den Dienst der gewünschten Domain vertreten darf.

GSS_C_NT_DOMAINBASED_SERVICE bewahrt den fehlenden Umfang in der Form service [AT] domain [AT] hostname. Der Dienst benennt die Funktion, die Domain den bedienten Bereich und der Host den konkreten Acceptor. IANA registriert den Namenstyp als Wert 5.

Ein Credential für diese Dreierkombination verkörpert nach RFC 5178 die Autorisierung des Hosts für den Domain-weiten Dienst. Seine Ausstellung ist deshalb eine Delegation. DNS veröffentlicht eine mögliche Adresse; der Credential-Aussteller entscheidet, welche dieser Maschinen im Namen des Dienstbereichs sprechen kann.

Die Kerberos-Abbildung erhält drei Komponenten

RFC 5179 definiert die mechanismusspezifische Abbildung. Der Service wird die erste Komponente des Kerberos-Principals, der Hostname die zweite und die Domain die dritte. Empfohlen wird der Kerberos-Namenstyp NT-SRV-HST-DOMAIN mit dem Wert 12; NT-UNKNOWN bleibt zulässig.

Für ein generisches ldap [AT] foo.example [AT] ds1.foo.example zeigt die Spezifikation als mögliches Principal eine Form, in der LDAP, der konkrete Server und foo.example getrennt erhalten bleiben. Der Realm folgt der normalen Kerberos-Zuordnung zur Domain, als wäre sie ein Hostname.

Die Sicherheitsanforderung präzisiert jedoch die Quelle: Der Realm domain-basierter Principals muss aus dem Hostnamen abgeleitet werden, nicht aus dem Domain-Slot des eingegebenen Namens. Der Dienstbereich darf nicht durch bloße Eingabe die Vertrauenskette auswählen, die seine eigene Berechtigung bestätigt.

Damit entstehen vier prüfbare Werte: eingegebener Dienstbereich, eingegebener Host, kanonisches Principal und verwendeter Realm. Eine Konfiguration, die nur den ersten String protokolliert, kann nicht belegen, was die Kerberos-Bibliothek tatsächlich authentisiert hat.

Syntaxannahme ist noch keine semantische Übereinstimmung

Kerberos-Anwendungen sollten deshalb nicht nur testen, ob ein Parser den Namen akzeptiert. Sie müssen feststellen, welches Principal der aktive Mechanismus erzeugt, welcher Realm kontaktiert wurde, welches Credential antwortete und welchen Namen der Kontext zurückgab.

RFC 5179 entstand, als die Internationalisierung des Kerberos-Kernprotokolls noch unvollständig war. Es verlangt für internationalisierte Host- und Domain-Komponenten ACE. RFC 5178 führt parallel klassische und UTF-8-orientierte Import- und Display-Schnittstellen ein. Klassischer Import akzeptiert ACE; UTF-8-Import akzeptiert UTF-8 und ACE. Klassische Anzeige liefert ASCII oder ACE, UTF-8-Anzeige liefert UTF-8 und kein ACE.

Diese Schnittstellen sind keine Garantie für String-Rundreisen. GSS-API unterscheidet interne Namen, Mechanism Names, Anzeigenamen und exportierte Formen. RFC 2743 warnt, dass Display nach Import weder denselben Text noch zwingend denselben Namenstyp zurückgibt. GSS_Compare_name() und mechanismusspezifische Kanonisierung tragen die Gleichheitssemantik, nicht ein Vergleich zweier Logzeilen.

Hinzu kommt der historische Wechsel von RFC 3490 zu IDNA2008. Eine aktuelle Implementierung muss ihren Umgang mit A-Labels und U-Labels dokumentieren, ohne spätere Regeln rückwirkend in RFC 5178 hineinzulesen. Auditierbar sind nur Umwandlungen, deren Eingabe, Profil und End-Principal erhalten bleiben.

Credential-Ausgabe ist der ausführbare Beschluss

Wenn ein Host das Credential des Tripels besitzt, kann er die von RFC 5178 beabsichtigte Prüfung bestehen. Das gilt auch dann, wenn ein Administrator das Credential irrtümlich ausstellte oder nach dem Ausscheiden des Hosts nicht widerrief.

Der Kontrollpunkt liegt deshalb nicht allein beim GSS-Ergebnis. Benötigt werden Antrag, Genehmigung, Aussteller, Zielhost, Service-Domain, Laufzeit, Verteilung und Widerruf. Eine erfolgreiche Kryptoprüfung beweist Kontrolle über das Credential; sie bewertet nicht die fortdauernde organisatorische Richtigkeit seiner Ausgabe.

Auch Discovery- und Credential-Inventare dürfen nicht zu einem Statusfeld verschmelzen. Ein aus SRV entfernter, aber noch credentialisierter Host ist schwerer auffindbar, nicht machtlos. Ein veröffentlichter Host ohne Credential ist sichtbar, aber nicht bereit. Die Mengendifferenz zeigt Übergänge, die ein Feld „aktiv“ verstecken würde.

Fallback braucht eine zweite Autoritätsquelle

Nicht jeder GSS-Mechanismus und nicht jeder Acceptor unterstützt domain-basierte Namen. Besonders bestehende LDAP-Installationen können host-basierte Namen erwarten. Eine einseitige Umstellung kann Interoperabilität brechen.

RFC 5178 erlaubt den Rückfall, verlangt dann aber eine separate Prüfung, dass die Hostidentität den Dienst für die gewünschte Domain erbringen darf. Dasselbe gilt für Initiatoren ohne Unterstützung des Namenstyps.

Ein erfolgreicher Wiederholungsversuch liefert diese Prüfung nicht. Die alternative Autorisierung muss aus einer unabhängigen, verantworteten Liste oder Policy stammen. Wird dafür dieselbe unsichere SRV-Antwort verwendet, bestätigt die Entdeckung sich selbst.

Ein Betriebssystem sollte daher nicht nur „domain name failed, host name succeeded“ melden, sondern die Ersatzregel und deren Version. Sonst stellt der Kompatibilitätspfad die Verbindung wieder her, indem er den Anspruch verkleinert.

NFS ordnet die Schichten, ohne sie zu vereinigen

RFC 6641 nutzt SRV für die Wurzel eines organisationsweiten NFSv4-Namensraums. DNSSEC soll eingesetzt werden, wenn es verfügbar ist. Domain-basierte Principals bilden eine zusätzliche Kontrolle: Der ausgewählte Host authentisiert nfs [AT] Organisationsdomain [AT] Host.

DNS benennt mögliche Server. Kerberos bestätigt ein abgegrenztes Mandat. NFS verhandelt Sicherheit und autorisiert Operationen. Mount und Daten sind beobachtete Ergebnisse. Ein erfolgreicher Schritt macht die anderen nicht wahr.

Gerade die Realm-Regel zeigt das institutionelle Prinzip: minimale gemeinsame Struktur, lokal überprüfbare Abbildung und getrennte Zuständigkeit. Die Eingabe kann ihren Dienstbereich erklären. Der laufende Mechanismus bestimmt nach seinen Regeln den Realm. Der Credential-Aussteller trägt die Delegation. Die Anwendung entscheidet die Operation.

Der Host ist nicht der Dienstbereich, und der Dienstbereich ist nicht automatisch der Realm. Die Architektur bleibt sicherer, solange diese drei Namen nicht unter dem Etikett „Identität“ verschwinden.

Quellen