GSSAPI

Das Generic Security Services Application Program Interface (GSSAPI, auch GSS-API) ist eine Programmierschnittstelle für Anwendungen, die auf Security Devices zugreifen.

Die GSSAPI ist ein IETF-Standard, der das Problem vieler verschiedener, teilweise inkompatibler Security Devices adressiert.

Funktionsweise

Die GSSAPI selbst bietet keinerlei Sicherheit. Stattdessen bieten verschiedene Hersteller ihre Sicherheitssoftware an, oft in Form von Bibliotheken. Diese Bibliotheken präsentieren ein GSS-kompatibles Interface für Anwendungsprogrammierer, welche wiederum nur die herstellerunabhängige und standardisierte GSSAPI nutzen müssen. Wenn die Implementationen der Sicherheitsfunktionen irgendwann ausgetauscht werden müssen, bedarf es keiner Änderung an der Applikation.

Das wichtigste Feature der GSSAPI-Anwendungen ist der Austausch von undurchsichtigen Nachrichten (sogenannten Tokens), die die Implementierungsdetails vor den höheren Schichten der Anwendung verstecken. Die Client- und Serverseite der Implementation sind so gestaltet, dass sie die Tokens, die die jeweilige GSSAPI-Implementation liefert, übertragen. GSSAPI-Tokens können über unsichere Netzwerke (wie das Internet) ausgetauscht werden, denn ihr Mechanismus garantiert Nachrichtensicherheit. Nachdem eine gewisse Anzahl von Token ausgetauscht wurde, informiert die GSSAPI auf beiden Seiten die jeweilige Anwendung, dass eine sichere Verbindung installiert wurde.

Sobald diese sichere Verbindung aufgebaut wurde, können sensible Nachrichten der jeweiligen Anwendung in Tokens der GSSAPI verschlüsselt verpackt und sicher zwischen Client und Server übermittelt werden. Der typische Schutz, der durch die GSSAPI bereitgestellt wird, beinhaltet Vertrauen (Geheimhaltung) und Integrität (Echtheit). Die GSSAPI kann ebenfalls lokale Garantien über die Identität des entfernten Benutzers oder Rechners bereitstellen.

Die GSSAPI beschreibt etwa 45 Funktionsaufrufe. Besonders bedeutsam sind:

• GSS_Acquire_cred – erhält den Beweis für den User, oftmals ein kryptografischer Schlüssel
• GSS_Import_name – konvertiert einen eingegebenen Benutzer- oder Hostnamen in eine identifizierbare Form
• GSS_Init_sec_context – generiert ein neues Token, das zum Server geschickt wird
• GSS_Accept_sec_context – bearbeitet ein Token von GSS_Init_sec_context und generiert ein neues Token, das zurückgeschickt werden kann
• GSS_Wrap – konvertiert Anwendungsdaten in eine sichere Nachricht (typischerweise verschlüsselt)
• GSS_Unwrap – konvertiert eine sichere Nachricht zurück in Anwendungsdaten

Die GSSAPI ist für C und Java standardisiert. Ein Standard für C# befindet sich in der Entwicklung.

Eine Beschränkung der GSSAPI ist, dass nur die Authentifizierung (Beglaubigung), nicht jedoch die Autorisierung (Berechtigung) standardisiert wird, weiterhin wird eine Client-Server Architektur angenommen.

Verschiedene GSSAPI-Mechanismen arbeiten normalerweise nicht zusammen. Wenn für die Zukunft verschiedene andere GSSAPI-Mechanismen in großen, heterogenen Netzwerken erwartet werden, dürfte eine Implementierung von SPNEGO auf jeder Seite der Kommunikation sinnvoll sein. Dadurch können gängige GSSAPI-Mechanismen sicher zwischen zwei Partnern (Initiator und Empfänger) ausgehandelt werden. Microsoft hat SPNEGO in Windows 2000 eingebaut, als Kerberos 5 zum existierenden NTLM-SSP-Mechanismus hinzugefügt wurde.

Verbindung zu Kerberos

Die dominierende Implementierung der GSSAPI-Mechanismen, die derzeit genutzt wird, ist Kerberos. Die Kerberos-API ist jedoch nicht standardisiert, es existieren verschiedene Implementationen, die zueinander inkompatible APIs verwenden.

Konkurrierende Technologien

RADIUS, SASL, SSL.

Schlüsselkonzepte der GSSAPI

Name

ein binärer String, der den Prinzipal (den Benutzer oder das Programm) angibt – siehe Zugriffskontrolle und Identität. Als Beispiel nutzt Kerberos Namen wie user@REALM für Benutzer und service/hostname@REALM für Programme.

Credentials (Legimitation)

Informationen über die Identität; werden von einer Entität als benannter Principal genutzt. Credentials enthalten üblicherweise einen kryptografischen Schlüssel.

Kontext

Der Status einer Seite der beglaubigten/bestätigten Verbindung. Kann Dienste zum Schutz von Nachrichten enthalten, die zum Aufbau einer sicheren Verbindung genutzt werden.

Token

undurchsichtige Nachrichten, die entweder als Teil der initialen Authentifizierung (Kontext-Level-Token) oder als Teil der geschützten Kommunikation (Per-Nachricht-Token) ausgetauscht werden.

Mechanismus

Eine zugrundeliegende GSSAPI-Implementierung, die Namen, Token und Credentials bereitstellt. Bekannte Mechanismen beinhalten Kerberos, NTLM, DCE, SESAME, SPKM, LIPKEY.

Initiator/Empfänger

Das Ende, das das erste Token sendet, ist der Initiator, das andere Ende der Empfänger. Im Allgemeinen ist der Client der Initiator, während der Server der Empfänger ist.

Geschichte der GSSAPI

• Juli 1991: Die IETF Common Authentication Technology (CAT) Working Group trifft sich in Atlanta, geleitet von John Linn
• September 1993: GSSAPI Version 1 (RFC 1508, RFC 1509)
• Mai 1995: Windows NT 3.51 erscheint, enthält SSPI
• Juni 1996: Kerberos-Mechanismus für GSSAPI (RFC 1964)
• Januar 1997: GSSAPI Version 2 (RFC 2078)
• Oktober 1997: SASL veröffentlicht, enthält GSSAPI-Mechanismen (RFC 2222)
• Januar 2000: GSSAPI Version 2 Update 1 (RFC 2743, RFC 2744)
• August 2004: KITTEN-Arbeitsgruppe trifft sich, um CAT-Aktivitäten fortzusetzen
• Mai 2006: Secure-Shell-Nutzung der GSSAPI standardisiert (RFC 4462)

Weblinks

• RFC 4121 The Kerberos 5 GSS-API mechanism: Version 2 (englisch)
• RFC 4178 The Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) (englisch)
• RFC 2025 The Simple Public-Key GSS-API Mechanism (SPKM) (englisch)
• RFC 2847 LIPKEY – A Low Infrastructure Public Key Mechanism Using SPKM (englisch)
• Kitten working group – next generation GSS-API (englisch)