Zusammenfassung

  • RFC 1509 definierte gss_cred_id_t als für den Aufrufer opaken, atomaren Wert. Das eigentliche Credential blieb innerhalb der GSS-API; identische Handle-Werte konnten für verschiedene Aufrufer verschiedene Credentials erreichen.
  • Ein Handle konnte nur in einem Prozess, in dessen Kindprozessen oder unter Prozessen mit gemeinsamer lokaler Identifikation gelten. GSS_C_NO_CREDENTIAL konnte die Auswahl eines Standard-Credentials auslösen und bedeutete nicht zwingend, dass kein Principal verwendet wurde.
  • Handle, Credential, Name, Sicherheitskontext, übertragenes Token und Autorisierungsentscheidung waren getrennte Übergänge. Die gemeinsame Schnittstelle wurde tragfähig, weil sie diese Grenzen nicht zu einer einzigen Behauptung verdichtete.

Eine Zahl ohne ihren Namensraum

Betrachtet man einen C-Wert allein, scheint seine Gleichheit eindeutig. Zwei Zeiger haben dieselbe Darstellung; zwei Ganzzahlen denselben Inhalt. Für gss_cred_id_t entzog RFC 1509 dieser Gleichheit die globale Bedeutung.

Der Typ durfte arithmetisch oder zeigerartig implementiert werden, blieb für den Aufrufer aber undurchsichtig. Die Spezifikation hielt ausdrücklich fest, dass derselbe Wert bei verschiedenen Aufrufern auf verschiedene Credentials verweisen konnte. Eine Implementierung durfte den Geltungsbereich auf den erwerbenden Prozess begrenzen, dessen Kinder einbeziehen oder Prozesse mit einer gemeinsamen lokalen Identifikation wie einer UID zulassen.

Die Auflösung benötigte damit mehr als den sichtbaren Wert:

Aufrufer + Implementierungszustand und Epoche + Handle + Mechanismus → Credential

Auf einem anderen Host konnte die Zahl bedeutungslos sein. Nach einem Neustart konnte derselbe Tabellenplatz neu belegt werden. Unter einer anderen UID konnte ein anderer Namensraum antworten. Der Wert blieb exakt; die Voraussetzung seiner Interpretation hatte sich geändert.

Ein Audit, das nur den Handle behält, konserviert deshalb ein gutes Korrelationsmerkmal für einen engen Zeitraum, aber keinen dauerhaften Identitätsnachweis. Es hat die Aktennummer ohne Registerstelle und Ausgabezeitpunkt archiviert.

Die sensible Sache blieb hinter der Referenz

Ein Credential beschrieb einen Principal und verlieh seinem Inhaber die Möglichkeit, als dieser Principal aufzutreten. Die Anwendung erhielt jedoch nicht zwangsläufig Schlüssel, Tickets oder mechanismusspezifische Strukturen. Sie erhielt eine lokale Referenz auf Zustand, den GSS-API oder ein darunterliegender Mechanismus verwaltete.

Diese Indirektion diente zugleich Sicherheit und Portabilität. Anwendungen mussten weder Geheimnisse zerlegen noch die internen Formate jedes Mechanismus verstehen. Die Bindung konnte einen einheitlichen C-Typ anbieten, obwohl dahinter völlig unterschiedliche Verfahren standen.

RFC 1509 erklärte deshalb, der Handle selbst enthalte keine sicherheitsrelevanten Informationen und müsse von der Anwendung nicht besonders geschützt werden. Daraus folgte nicht, dass das Credential öffentlich war oder die Bits Autorität übertrugen. Die Kontrolle lag beim Resolver: Betriebssystem und Implementierung mussten bestimmen, welche Aufrufer die referenzierte Fähigkeit nutzen durften.

RFC 1508 wies diese Aufgabe systemnahen Mechanismen zu. Erwerb und Nutzung von Credentials sollten auf geeignete Prozesse beschränkt werden; ein Credential benutzen zu können hieß, die Identität des Principals behaupten zu können. Ob ein anderer Prozess es ebenfalls verwenden durfte, war eine lokale Regel und keine Eigenschaft der nackten Zahl.

Der Standardwert war keine Leerstelle

Besonders leicht ließ sich GSS_C_NO_CREDENTIAL missverstehen. Bei der Einrichtung eines Kontextes konnte die Konstante verlangen, ein Standard-Credential zu verwenden. Der Aufrufer verzichtete auf eine ausdrückliche Referenz; die Umgebung verzichtete damit nicht auf eine Identität.

RFC 1509 überließ Herstellung und Reichweite dieses Defaults der Implementierung. RFC 2078 konkretisierte die Auswahl nach ersten Implementierungserfahrungen. Möglich waren etwa der einzige Principal, den die Anwendung benutzen durfte, eine Standard-Netzwerkidentität, eine Netzwerkabbildung der lokalen Standardidentität oder eine benutzerdefinierte Wahl. Konnte kein geeignetes Credential bestimmt werden, gab es einen eigenen Fehlerweg.

Die Regel machte portable Anwendungen einfacher. Sie mussten weder lokale Credential-Stores noch die Konventionen einzelner Mechanismen kennen. Gleichzeitig wurde der tatsächlich handelnde Principal von Umgebungszustand und lokaler Politik abhängig. Derselbe Aufruf konnte auf zwei Systemen unterschiedliche Identitäten erhalten und dennoch vertragskonform sein.

Ein belastbarer Beleg muss daher den Wunsch nach Standardauflösung, die verwendete Regel, den gewählten Principal, den Mechanismus, Initiator- oder Acceptor-Verwendung und die Gültigkeitsdauer festhalten. „Kein Credential übergeben“ beschreibt nur ein Argument, nicht das Ergebnis.

Lebensdauer gehörte nicht dem Handle allein

Die räumliche Reichweite war nur eine Dimension. Ein Credential konnte verschwinden, wenn keine Handles mehr auf es verwiesen, und zusätzlich nach Regeln des Mechanismus ablaufen. Interne Plätze konnten freigegeben und später wiederverwendet werden.

Damit hatte die Referenz mindestens zwei zeitliche Grenzen: die Lebensdauer des Credentials und die Epoche des lokalen Resolvers. Selbst ein Zeitstempel reicht nicht, wenn Instanz und Neustartgrenze fehlen. Umgekehrt beweist eine gleichbleibende Prozessbezeichnung keine Kontinuität des internen Zustands.

Indirektion ermöglichte Widerruf, Austausch von Repräsentationen und Isolation zwischen Aufrufern. Ihr Preis war, dass die Referenz ohne Namensraum und Epoche kein dauerhaftes Beweisstück sein konnte. Genau diese Beschränkung gab der Implementierung den Spielraum, den die gemeinsame API brauchte.

Sicherheitskontext und Verbindung waren nicht dasselbe

Auch gss_ctx_id_t war ein aufruferbezogener, opaker Wert. Dahinter hielt die Implementierung den kryptografischen Zustand eines Endes einer Peer-Beziehung. Dieser Sicherheitskontext war jedoch nicht mit einer Transportverbindung identisch.

Eine Kommunikationssitzung konnte mehrere Verbindungen durchlaufen; mehrere Kontexte konnten nacheinander oder gleichzeitig in einer Kommunikationsbeziehung bestehen. Eine Socket-Kennung bewies daher nicht den GSS-Kontext. Ein vorhandener Kontext bewies seinerseits nicht, dass jede Nachricht Integrität oder Vertraulichkeit erhalten hatte.

Die Anwendung musste Tokens transportieren und richtig zuordnen, Major Status und mechanismusspezifischen Status lesen, angeforderte und zurückgegebene Dienste vergleichen und anschließend autorisieren. Selbst danach blieb zu beobachten, ob die beabsichtigte Änderung tatsächlich, vollständig und dauerhaft eingetreten war.

Authentisierung, Nachrichtenschutz, Autorisierung und Wirkung waren vier verschiedene Schlüsse. Die Schnittstelle half, sie zu verbinden, ersetzte aber keinen davon durch einen pauschalen Erfolg.

Über Grenzen ging ein eigens gebautes Token

Authentisierungstokens waren ebenfalls opak, doch ihr Auftrag unterschied sich. Ein Mechanismus erzeugte eine Bitfolge, die Anwendung transportierte sie, der Peer-Mechanismus verarbeitete sie. Das Token besaß einen definierten Weg über die Grenze; ein lokaler Credential-Handle besaß ihn nicht.

Channel Bindings verbanden Adresstypen, Adressen und Anwendungsdaten mit dem Kontextaufbau. Unterschiedliche Eingaben konnten GSS_S_BAD_BINDINGS auslösen. Der Vergleich belegte die Übereinstimmung der bereitgestellten Werte, nicht jede physische oder administrative Eigenschaft des Kanals. Weil ein Mechanismus die Bindungsdaten selbst in ein Token aufnehmen konnte, warnte RFC 1509 vor vertraulichen Inhalten.

RFC 2744 zeigte später, wie ein wirklicher Prozesswechsel eines Sicherheitskontextes aussah. gss_export_sec_context deaktivierte den Kontext im Quellprozess und erzeugte ein Interprozess-Token; gss_import_sec_context nahm es am Ziel auf. Es sollte nur eine aktive Instanz geben, und lokale Regeln konnten den Import auf ein Konto oder eine Prozessgruppe einschränken.

Das Export-Token konnte Schlüsselmaterial enthalten und musste beim Transport geschützt werden. Damit trug es eine andere Pflicht als der lokale Handle. Zustand bewegte sich erst durch eine ausdrückliche Transformation mit Quell- und Zielwirkung. Das Kopieren einer Handle-Darstellung war nie eine solche Übertragung.

Ein angezeigter Name blieb eine Projektion

Bei Namen zog RFC 1509 eine vergleichbare Grenze. Druckbare Namen dienten Menschen und konnten von lokaler Konfiguration oder persönlicher Präferenz abhängen. Interne Namen dienten der API. Eine Objektkennung bezeichnete den Namensraum; die interne Form bewahrte genügend Typinformation, um unpassende Namensräume nicht zu vermischen.

Import, Anzeige und Vergleich sollten über GSS-API-Operationen erfolgen. Zeichenkettengleichheit war keine allgemeine Identitätsregel. RFC 2744 stellte später klar, dass die Anzeige eines importierten internen Namens nicht dieselbe Zeichenfolge zurückgeben musste. Eine DNS-Form konnte intern in X.500 überführt und entsprechend anders dargestellt werden.

Der Name auf einem Bildschirm war deshalb ein Darstellungsbeleg, nicht die gesamte Authentisierung. Für eine belastbare Zuordnung brauchte man Namensraum, Mechanismus, internes Vergleichsergebnis, lokale Kontenzuordnung und Anwendungsentscheidung. Gleich aussehende Namen konnten verschieden typisiert sein; verschieden aussehende Namen konnten dieselbe interne Entität abbilden.

Die gemeinsame API vereinheitlichte den Aufruf

RFC 1511 beschrieb die Arbeit der Common Authentication Technology Working Group als Arbeitsteilung. Sicherheitsspezialisten sollten wiederverwendbare Mechanismen bereitstellen; Protokolldesigner sollten eine generische Schnittstelle integrieren. RFC 1508 lieferte das sprachunabhängige Konzept, RFC 1509 die C-Typen und Funktionen.

Vereinheitlicht wurde nicht jede Credential-Verwaltung. Aufbewahrung, Prozessberechtigung, Standardidentität, Namensabbildung und Handle-Reichweite blieben lokal. RFC 2078 überarbeitete das Modell nach Implementierungserfahrung. RFC 2743 und RFC 2744 ersetzten die frühen Texte später durch Version 2 Update 1 und deren C-Bindung.

Die Nachfolger ergänzten Operationen und Präzision, hielten aber an einer Grenze fest: Die bloße Verwendung von GSS-API garantierte kein bestimmtes Sicherheitsniveau. Entscheidend waren der zugrunde liegende Mechanismus und die korrekte Anforderung und Auswertung der Dienste durch den Aufrufer.

Gerade diese schmale gemeinsame Fläche erleichterte freiwillige Adoption. Das anfängliche Minimum lokalisierte künftige Entscheidungen, statt alle Systeme auf eine einzige Credential-Ordnung festzulegen. Der Preis war eine starke lokale Instanz, deren Rolle in Beobachtung und Governance sichtbar bleiben musste.

Was die Quellen belegen können

Die Dokumente belegen Spezifikationssprache und Nachfolge. Sie zeigen, dass RFC 1509 gleiche Handle-Werte bewusst aufruferabhängig machte, Handles von Credentials und Tokens trennte und wesentliche Kontrollen lokalen Implementierungen überließ. Die späteren RFCs präzisierten Default-Auflösung, Namen und expliziten Kontexttransfer.

Sie belegen nicht, welche Repräsentation eine bestimmte Bibliothek wählte, welche Reichweite ein konkretes Betriebssystem nutzte, ob eine Anwendung alle Ergebnisse prüfte oder ob ein Angriff stattfand. „Proposed Standard“ ist ein Publikationsstatus, keine Einsatzstatistik. Aus einer normativen Möglichkeit folgt kein beobachtetes Ereignis.

Die historische Aussage bleibt dennoch klar. Bereits 1993 verweigerte eine Sicherheits-API der kleinen Zahl die Rolle eines universellen Autoritätsbeweises. Wer eine Wirkung einem Principal zuschreiben will, braucht Aufrufer, Resolver, Epoche, Mechanismus, Kontext, Autorisierungsentscheidung und beobachtete Folge. Der Handle war nur ein lokaler Wegweiser durch diese Kette.

Quellen