Sicherheitsvarianten

Dieser Abschnitt beschreibt die Entwicklung und den Ursprung der RPCSEC_GSS API.

Sicherheit vor der RPCSEC_GSS

Eine der ersten von RPC unterstützten Sicherheitsvarianten stellte AUTH_SYS dar (auch als AUTH_UNIX bekannt). AUTH_SYS stellte über Benutzer- und Gruppen-IDs einen Berechtigungsnachweis im UNIX-Format bereit, um den Sender und Empfänger einer Nachricht zu identifizieren. Die Implementierung von AUTH_SYS gestaltet sich einfach; allerdings ist sie auch einfach zu umgehen, da sie keine wirkliche Authentisierung bietet -- d. h., es gibt für einen Server keine Möglichkeit zu verifizieren, ob ein Client auch das ist, was er vorgibt zu sein. Daher ist es relativ einfach eine Netzwerkanforderung unter AUTH_SYS zu fälschen.

Kurz nach AUTH_SYS ist die Sicherheitsvariante AUTH_DES erschienen. AUTH_DES basiert auf der Authentisierung mit einem öffentlichen Schlüssel -- es verwendet den Austausch eines Diffie-Hellman-Schlüssels, um einen gemeinsamen Schlüssel zwischen dem privaten Schlüssel eines Clients und dem öffentlichen Schlüssel eines Servers zu erzeugen. Der gemeinsame Schlüssel wird dann für die Verschlüsselung eines DES-Sitzungsschlüssels verwendet, den ein Server anschließend entschlüsselt, um eine Sitzung einzurichten.

Obwohl AUTH_DES einen wesentlichen Vortschritt zu AUTH_SYS darstellt, besitzt es doch für eine weitläufige Verwendung einige Einschränkungen. Der Haupteinwand besteht für viele Leute in der Schlüsselgröße, die nach heutigen Verschlüsselungsstandards etwas zu klein geraten ist.

Schließlich wurde eine weitere RPC-Sicherheitsvariante eingeführt. Das auf Kerberos V4 basierende AUTH_KERB bietet eine noch höhere Sicherheit als AUTH_DES oder AUTH_SYS. Jedoch kann auch AUTH_KERB entschlüsselt werden.

Weitere Informationen über diese Sicherheitsvarianten finden Sie unter ONC+ Developer's Guide.

Integrität und Vertraulichkeit: Die GSS-API

Es wurde eine neue Netzwerkebene, die Generic Security Standard API oder auch GSS-API hinzugefügt, um die Sicherheit zu erhöhen. Das GSS-API-Framework umfaßt zwei zusätzliche Sicherheits-Services, die über die Authentisierung hinausgehen:

• Integrität. Mit dem Service für die Integrität verwendet die GSS-API den zugrundeliegenden Mechanismus für die Authentisierung von Nachrichten, die zwischen Programmen ausgetauscht werden. Folgendes wird durch kryptografische Prüfsummen nachgewiesen:

  • Die Identität des Senders für den Empfänger

  • Die Identität des Empfängers für den Sender (wenn die gegenseitige Authentisierung erforderlich ist)

  • Die Authentizität der übertragenen Daten selbst

• Vertraulichkeit. Der Service für die Vertraulichkeit umfaßt den Service für die Integrität. Zusätzlich werden die übertragenen Daten verschlüsselt, um sie vor unberechtigter Einsichtnahme zu schützen.

  Aufgrund der U.S.-Exportbeschränkungen ist der Vertraulichkeits-Service vielleicht nicht für alle SEAM-Benutzer verfügbar.

Zur Zeit wurde die GSS-API noch nicht offengelegt. Bestimmte Funktionen der GSS-API sind jedoch über RPCSEC_GSS-Funktionen "sichtbar" -- diese können auf "opake" (nicht transparente) Weise verändert werden. Der Programmierer muß nicht direkt mit ihren Werten arbeiten.

Die RPCSEC_GSS API

Die RPCSEC_GSS-Sicherheitsvariante ermöglicht es ONC RPC-Anwendungen, die Vorteile der GSS-API-Funktionen zu nutzen. RPCSEC_GSS befindet sich wie folgt "über" der GSS-API-Ebene:

Abbildung 8-1 GSS-API und RPCSEC_GSS, Sicherheitsebenen

Folgendes kann über die Verwendung der Schnittstelle für RPCSEC_GSS von ONC RPC festgelegt werden:

Mechanismus

Ein Sicherheits-Muster. Jeder unterschiedliche Sicherheitsmechanismus bietet eine andere Art des Datenschutzes sowie eine oder mehrere Stufen für den Datenschutz. In diesem Fall handelt es sich um jeden von der GSS-API unterstützten Sicherheitsmechanismus (Kerberos V5, RSA Public Key usw.)

Sicherheits-Service

Entweder Vertraulichkeit oder Integrität (oder keiner). Integrität wird als Standard verwendet. Der Service ist vom Mechanismus unabhängig.

QOP

Schutzumfang. Der Schutzumfang (QOP, Quality of Protection) legt den für die Implementierung der Services für Vertraulichkeit oder Integrität verwendeten Typ des kryptografischen Algorithmusses fest. Mit jedem Sicherheitsmechanismus können ein oder mehrere QOPs verbunden sein.

Anwendungen können Listen gültiger QOPs und Mechanismen über Funktionen erhalten, die von RPCSEC_GSS bereitgestellt werden. (Siehe "Sonstige Funktionen".) Entwickler sollten festcodierte Mechanismen und QOPs in ihren Anwendungen vermeiden, damit die Anwendungen nicht verändert werden müssen, um neue oder unterschiedliche Mechanismen bzw. QOPs zu verwenden.

Historisch gesehen hatten die Begriffe "Sicherheitsvariante" und "Authentisierungsvariante" dieselbe Bedeutung. Mit der Einführung von RPCSEC_GSS hat der Begriff "Variante" eine etwas andere Bedeutung erhalten. Eine Variante kann jetzt auch zusammen mit der Authentisierung einen Service (Integrität oder Vertraulichkeit) einbeziehen, obwohl RPCSEC_GSS momentan die einzige Variante ist, die dies unterstützt.

Mit RPCSEC_GSS können ONC RPC-Anwendungen ebenso wie mit anderen Varianten einen Sicherheitskontext mit einem Peer einrichten, Daten austauschen und den Kontext wieder vernichten. Nachdem ein Kontext eingerichtet wurde, kann die Anwendung den QOP und den Service für jede gesendete Dateneinheit ändern.

Weitere Informationen über RPCSEC_GSS, einschließlich der Datentypen von RPCSEC_GSS, finden Sie in der Online-Dokumentation zu rpcsec_gss(3N).