„GSSAPI“ – Versionsunterschied

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
Versionsgeschichte interaktiv durchsuchen
[gesichtete Version][gesichtete Version]
← Zum vorherigen Versionsunterschied
Inhalt gelöscht Inhalt hinzugefügt
VisuellWikitext
tk k
 
Zeile 37: Zeile 37:
* [[Security Support Provider Interface]] (SSPI) ist eine von Microsoft veröffentlichte, proprietäre Abart der GSSAPI
* [[Security Support Provider Interface]] (SSPI) ist eine von Microsoft veröffentlichte, proprietäre Abart der GSSAPI
<!-- später übersetzen
<!-- später übersetzen
The [[Microsoft Windows]] [[Security Service Provider Interface]] (SSPI) is a proprietary variant of GSS-API with extensions and very Windows-specific data types. It was shipped with Windows NT 3.51 and Windows 95 with the NT [[LAN Manager]] [[Security Support Provider]] (NTLM SSP). For Windows 2000 an Implementation of Kerberos 5 was added, using token formats conforming to the official protocol standard RFC&nbsp;1964 (The Kerberos 5 GSS-API mechanism) and providing wire-level interoperability with Kerberos 5 implementations from other vendors.
The [[Microsoft Windows]] [[Security Service Provider Interface]] (SSPI) is a proprietary variant of GSS-API with extensions and very Windows-specific data types. It was shipped with Windows NT 3.51 and Windows 95 with the NT [[LAN Manager]] [[Security Support Provider]] (NTLM SSP). For Windows 2000 an Implementation of Kerberos 5 was added, using token formats conforming to the official protocol standard <nowiki>RFC&nbsp;1964</nowiki> (The Kerberos 5 GSS-API mechanism) and providing wire-level interoperability with Kerberos&nbsp;5 implementations from other vendors.
One significant shortcoming of SSPI is its lack of channel bindings, which may preclude interoperability for some GSS-API enabled application protocols.
One significant shortcoming of SSPI is its lack of channel bindings, which may preclude interoperability for some GSS-API enabled application protocols.


One fundamental difference between the IETF-defined GSS-API and Microsoft's SSPI is the concept of "impersonation". In this model, a server can switch to and operate with the FULL privileges of the authenticated client, so that the Operating system performs all access control checks, e.g. when opening new files. Whether these are less privileges or more privileges than that of the original service account depends entirely on which client connects/authenticates. In the traditional (GSS-API) model, a server runs under a service account, can not elevate its privileges, and has to perform access control in a client- and application-specific fashion. The obvious negative security implications of the impersonation concept are mitigated in the most recent version of Windows by restricting impersonation to selected service accounts.
One fundamental difference between the IETF-defined GSS-API and Microsoft's SSPI is the concept of “impersonation”. In this model, a server can switch to and operate with the FULL privileges of the authenticated client, so that the Operating system performs all access control checks, e.g. when opening new files. Whether these are less privileges or more privileges than that of the original service account depends entirely on which client connects/authenticates. In the traditional (GSS-API) model, a server runs under a service account, can not elevate its privileges, and has to perform access control in a client- and application-specific fashion. The obvious negative security implications of the impersonation concept are mitigated in the most recent version of Windows by restricting impersonation to selected service accounts.
-->
-->


Aktuelle Version vom 27. März 2024, 16:23 Uhr

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

[Bearbeiten | Quelltext bearbeiten]

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

[Bearbeiten | Quelltext bearbeiten]

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

[Bearbeiten | Quelltext bearbeiten]

Schlüsselkonzepte der GSSAPI

[Bearbeiten | Quelltext bearbeiten]
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

[Bearbeiten | Quelltext bearbeiten]
  • 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])
[Bearbeiten | Quelltext bearbeiten]
  • 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

[Bearbeiten | Quelltext bearbeiten]
  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).
Abgerufen von „https://de.wikipedia.org/w/index.php?title=GSSAPI&oldid=243493083“