GSSAPI

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

Die GSSAPI ist ein Internetstandard der IETF, 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 Vertraulichkeit (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

Remote Authentication Dial-In User Service (RADIUS)
Simple Authentication and Security Layer (SASL)
Security Support Provider Interface (SSPI) ist eine von Microsoft veröffentlichte, proprietäre Abart der GSSAPI

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 (Legitimation): 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,^[1] RFC 1509^[2])
Mai 1995: Windows NT 3.51 erscheint, enthält SSPI
Juni 1996: Kerberos-Mechanismus für GSSAPI (RFC 1964^[3])
Januar 1997: GSSAPI Version 2 (RFC 2078^[4])
Oktober 1997: SASL veröffentlicht, enthält GSSAPI-Mechanismen (RFC 2222^[5])
Januar 2000: GSSAPI Version 2 Update 1 (RFC 2743,^[6] RFC 2744^[7])
August 2004: KITTEN-Arbeitsgruppe trifft sich, um CAT-Aktivitäten fortzusetzen
Mai 2006: Secure-Shell-Nutzung der GSSAPI standardisiert (RFC 4462^[8])

Weblinks

RFC: 4121 – The Kerberos 5 GSS-API mechanism: Version 2 (englisch). (englisch).
RFC: 4178 – The Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) (englisch). (englisch).
RFC: 2025 – The Simple Public-Key GSS-API Mechanism (SPKM) (englisch). (englisch).
RFC: 2847 – LIPKEY – A Low Infrastructure Public Key Mechanism Using SPKM (englisch). (englisch).
RFC: 6616 – A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID. (englisch).
Kitten working group – next generation GSS-API. ietf.org (englisch).

Einzelnachweise

↑ RFC: 1508 – Generic Security Service Application Program Interface. September 1993 (englisch).
↑ RFC: 1509 – Generic Security Service API: C-bindings. September 1993 (englisch).
↑ RFC: 1964 – The Kerberos Version 5 GSS-API Mechanism. Juni 1996 (englisch).
↑ RFC: 2078 – Generic Security Service Application Program Interface, Version 2. Januar 1997 (englisch).
↑ RFC: 2222 – Simple Authentication and Security Layer (SASL). (englisch).
↑ RFC: 2743 – Generic Security Service Application Program Interface Version 2, Update 1. Januar 2000 (englisch).
↑ RFC: 2744 – Generic Security Service API Version 2: C-bindings. Januar 2000 (englisch).
↑ RFC: 4462 – Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol. Mai 2006 (englisch).

[1] RFC: 1508 – Generic Security Service Application Program Interface. September 1993 (englisch).

[2] RFC: 1509 – Generic Security Service API: C-bindings. September 1993 (englisch).

[3] RFC: 1964 – The Kerberos Version 5 GSS-API Mechanism. Juni 1996 (englisch).

[4] RFC: 2078 – Generic Security Service Application Program Interface, Version 2. Januar 1997 (englisch).

[5] RFC: 2222 – Simple Authentication and Security Layer (SASL). (englisch).

[6] RFC: 2743 – Generic Security Service Application Program Interface Version 2, Update 1. Januar 2000 (englisch).

[7] RFC: 2744 – Generic Security Service API Version 2: C-bindings. Januar 2000 (englisch).

[8] RFC: 4462 – Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol. Mai 2006 (englisch).

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]