Kerberos ist ein Computernetzbeglaubigungsprotokoll, das auf der Grundlage von "Karten" arbeitet, um Knoten zu erlauben, die über ein nichtsicheres Netz kommunizieren, ihre Identität einander auf eine sichere Weise zu beweisen. Seine Entwerfer haben in erster Linie nach einem Client/Server-Modell gezielt, und es stellt gegenseitige Beglaubigung zur Verfügung — sowohl der Benutzer als auch der Server prüfen jede Identität eines anderen nach. Protokoll-Nachrichten von Kerberos werden gegen das Lauschen und die Wiederholungsspiel-Angriffe geschützt.

Kerberos baut auf symmetrische Schlüsselgeheimschrift und verlangt einen vertrauten Dritten, und kann fakultativ Geheimschrift des öffentlichen Schlüssels verwenden, indem er asymmetrische Schlüsselgeheimschrift während bestimmter Phasen der Beglaubigung verwertet. Kerberos verwendet Hafen 88 standardmäßig.

"Kerberos" bezieht sich auch auf ein Gefolge der kostenlosen Software, die vom Institut von Massachusetts für die Technologie (MIT) veröffentlicht ist, der das Protokoll von Kerberos durchführt.

Geschichte und Entwicklung

MIT hat Kerberos entwickelt, um Netzdienste zu schützen, die durch das Projekt Athena zur Verfügung gestellt sind. Das Protokoll wurde nach dem Charakter Kerberos (oder Zerberus) von der griechischen Mythologie genannt, die ein monströser dreiköpfiger Schutzhund von Hades war. Mehrere Versionen des Protokolls bestehen; Versionen 1-3 sind nur innerlich an MIT vorgekommen.

Steve Miller und Clifford Neuman, die primären Entwerfer der Version 4 von Kerberos, haben diese Version gegen Ende der 1980er Jahre veröffentlicht, obwohl sie es in erster Linie für das Projekt Athena ins Visier genommen hatten.

Version 5, die von John Kohl und Clifford Neuman entworfen ist, ist als RFC 1510 1993 erschienen (hat veraltet durch RFC 4120 2005 gemacht), mit der Absicht, die Beschränkungen und Sicherheitsprobleme der Version 4 zu überwinden.

MIT macht eine Durchführung von Kerberos frei verfügbar, unter der Urheberrechtserlaubnis ähnlich denjenigen, die für BSD verwendet sind. 2007 hat MIT das Kerberos Konsortium gebildet, um fortgesetzte Entwicklung zu fördern. Gründende Förderer schließen Verkäufer wie Orakel, Apple Inc., Google, Microsoft, Centrify Corporation und TeamF1 Inc. und akademische Einrichtungen wie KTH-königliches Institut für die Technologie, Universität von Stanford, MIT und Verkäufer wie CyberSafe ein, der gewerblich unterstützte Versionen anbietet.

Behörden in den Vereinigten Staaten haben Kerberos als militärische Hilfstechnologie klassifiziert und haben seinen Export verboten, weil es den DES Verschlüsselungsalgorithmus (mit 56-Bit-Schlüsseln) verwendet hat. Nichtamerikanischer Kerberos 4 Durchführung, KTH-KRB, der am Königlichen Institut für die Technologie in Schweden entwickelt ist, hat das System außerhalb der Vereinigten Staaten vor den Vereinigten Staaten bereitgestellt, hat seine Geheimschrift-Exportregulierungen (um 2000) geändert. Die schwedische Durchführung hat auf genanntem eBones. einer beschränkten Version eBones basiert hat auf der exportierten MIT Knochen-Ausgabe (beraubt sowohl der Verschlüsselungsfunktionen als auch der Anrufe zu ihnen) gestützt auf der Version Kerberos 4 Fleck-Niveau 9 basiert.

Windows 2000 und späterer Gebrauch Kerberos als ihre Verzug-Beglaubigungsmethode. Einige Hinzufügungen von Microsoft zum Gefolge von Kerberos von Protokollen werden in RFC 3244 "Microsoft Windows 2000 Kerberos Change Password und Satz-Kennwort-Protokolle" dokumentiert. RFC 4757 Dokumente der Gebrauch des Microsofts der RC4 Ziffer. Während Microsoft das Protokoll von Kerberos verwendet, verwendet es die MIT Software nicht.

Viele UNIX und UNIX ähnliche Betriebssysteme, einschließlich FreeBSD, Mac OS X des Apfels, Roten Hut-Unternehmens Linux, der Solaris des Orakels, der AIX von IBM, OpenVMS des HP, und andere, schließen Software für die Beglaubigung von Kerberos von Benutzern oder Dienstleistungen ein. Die eingebettete Durchführung des Kerberos V Beglaubigungsprotokoll für Kundenagenten und Netzdienste, die auf eingebetteten Plattformen laufen, ist auch von Gesellschaften wie TeamF1, Inc. verfügbar

, der IETF Kerberos Arbeitsgruppe aktualisiert die Spezifizierungen. Neue Aktualisierungen schließen ein:

• Verschlüsselung und Kontrollsumme-Spezifizierungen" (RFC 3961).
• Verschlüsselung von Advanced Encryption Standard (AES) für Kerberos 5 (RFC 3962).
• Eine neue Ausgabe der Spezifizierung von Kerberos V5 "Der Kerberos Netzbeglaubigungsdienst (V5)" (RFC 4120). Diese Version obsoletes RFC 1510, klärt Aspekte des Protokolls und beabsichtigten Gebrauches in einer ausführlicheren und klareren Erklärung.
• Eine neue Ausgabe der GSS-API-Spezifizierung "Die Kerberos Version 5 Allgemeine Sicherheitsdienstanwendungsprogramm-Schnittstelle (GSS-API) Mechanismus: Version 2." (RFC 4121).

Protokoll

Beschreibung

Der Kunde beglaubigt sich zu Authentication Server (AS) der vorwärts der Benutzername zu Key Distribution Center (KDC). Der KDC gibt Ticket Granting Ticket (TGT) aus, die Zeit gestampft, encrypts er mit dem Kennwort des Benutzers ist und das Encrypted-Ergebnis in den Arbeitsplatz des Benutzers zurückgibt. Wenn erfolgreich, gibt das den Benutzertischzugang.

Wenn der Kunde mit einem anderen Knoten kommunizieren muss ("Rektor" im Sprachgebrauch von Kerberos), sendet es den TGT an Ticket Granting Service (TGS), der denselben Gastgeber wie der KDC teilt. Nach dem Überprüfen des TGT ist gültig, und dem Benutzer wird erlaubt, auf den gebetenen Dienst zuzugreifen, der TGS gibt eine Karte und Sitzungsschlüssel aus, die dem Kunden zurückgegeben werden.

Der Kunde sendet dann die Karte und Schlüssel zum Dienstserver (SS).

Hier ist eine andere Beschreibung.

Der Kunde beglaubigt zu ALS einmal das Verwenden eines langfristigen geteilten Geheimnisses (z.B ein Kennwort) und empfängt Ticket Granting Ticket (TGT) von ALS. Später, wenn sich der Kunde mit einem SS in Verbindung setzen will, kann er (re), diese Karte zu verwenden, um zusätzliche Karten von TGS für SS zu bekommen, ohne das Verwenden des geteilten Geheimnisses aufzusuchen. Die letzten Karten können verwendet werden, um Beglaubigung dem SS zu beweisen.

Über die Phasen wird unten ausführlich berichtet.

Benutzer kundenbasierter Logon

1. Ein Benutzer geht in einen Benutzernamen und Kennwort auf der Kundenmaschine ein.
2. Der Kunde führt eine Einwegfunktion (Kuddelmuddel gewöhnlich) auf dem eingegangenen Kennwort durch, und das wird der heimliche Schlüssel des Kunden/Benutzers.

Kundenbeglaubigung

1. Der Kunde sendet eine Klartext-Nachricht des Benutzerpersonalausweises zu ALS Anforderung von Dienstleistungen im Auftrag des Benutzers. (Bemerken Sie: Weder der heimliche Schlüssel noch das Kennwort werden an ALS gesandt.), WIE den heimlichen Schlüssel durch hashing das Kennwort des Benutzers erzeugt, der an der Datenbank (z.B Aktives Verzeichnis im Windows-Server) gefunden ist.
2. ALS Kontrollen, um zu sehen, ob der Kunde in seiner Datenbank ist. Wenn es, ist, WIE die folgenden zwei Nachrichten dem Kunden zurücksendet:
3. * Nachricht A: Client/TGS Sitzungsschlüssel encrypted das Verwenden des heimlichen Schlüssels des Kunden/Benutzers.
4. * Nachricht B: Bewilligen-Karte der Karte (der den Kundenpersonalausweis, die Kundennetzadresse, Karte-Gültigkeitsperiode und der client/TGS Sitzungsschlüssel einschließt), encrypted das Verwenden des heimlichen Schlüssels des TGS.
5. Sobald der Kunde Nachrichten A und B erhält, versucht er, Nachricht A mit dem heimlichen Schlüssel zu entschlüsseln, der vom vom Benutzer eingegangenen Kennwort erzeugt ist. Wenn der Benutzer hereingegangen ist, vergleicht Kennwort das Kennwort in ALS Datenbank nicht, der heimliche Schlüssel des Kunden wird verschieden und so unfähig sein, Nachricht A zu entschlüsseln. Mit einem gültigen Kennwort und heimlichem Schlüssel entschlüsselt der Kunde Nachricht A, um den Client/TGS Sitzungsschlüssel zu erhalten. Dieser Sitzungsschlüssel wird für weitere Kommunikationen mit dem TGS verwendet. (Bemerken Sie: Der Kunde kann Nachricht B nicht entschlüsseln, weil es encrypted das Verwenden des heimlichen Schlüssels von TGS ist.) An diesem Punkt hat der Kunde genug Information, um sich zum TGS zu beglaubigen.

Kundendienstgenehmigung

Wenn

1. er um Dienstleistungen bittet, sendet der Kunde die folgenden zwei Nachrichten an den TGS:
2. * Nachricht C: Zusammengesetzt aus dem TGT aus der Nachricht B und dem Personalausweis des gebetenen Dienstes.
3. * Nachricht D: Authenticator (der aus dem Kundenpersonalausweis und dem Zeitstempel zusammengesetzt wird), encrypted das Verwenden des Client/TGS Sitzungsschlüssels.
4. Nach dem Empfang von Nachrichten C und D bekommt der TGS Nachricht B aus der Nachricht C wieder. Es entschlüsselt Nachricht B mit dem TGS heimlichen Schlüssel. Das gibt es "client/TGS Sitzungsschlüssel". Mit diesem Schlüssel entschlüsselt der TGS Nachricht D (Authenticator) und sendet die folgenden zwei Nachrichten dem Kunden:
5. * Nachricht E: Karte des Kunden zum Server (der den Kundenpersonalausweis, die Kundennetzadresse, Gültigkeitsperiode und Client-Server-Sitzungsschlüssel einschließt), encrypted das Verwenden des heimlichen Schlüssels des Dienstes.
6. * Nachricht F: Client-Server-Sitzungsschlüssel encrypted mit dem Client/TGS Sitzungsschlüssel.

Kundenserviceanforderung

1. Nach dem Empfang von Nachrichten E und F von TGS hat der Kunde genug Information, um sich zum SS zu beglaubigen. Der Kunde steht zum SS in Verbindung und sendet die folgenden zwei Nachrichten:
2. * Nachricht E vom vorherigen Schritt (die Karte des Kunden zum Server, encrypted das Verwenden des heimlichen Schlüssels des Dienstes).
3. * Nachricht G: Neuer Authenticator, der den Kundenpersonalausweis, Zeitstempel einschließt und encrypted das Verwenden des Client-Server-Sitzungsschlüssels ist.
4. Der SS entschlüsselt die Karte mit seinem eigenen heimlichen Schlüssel, den Client-Server-Sitzungsschlüssel wiederzubekommen. Mit dem Sitzungsschlüssel entschlüsselt SS Authenticator und sendet die folgende Nachricht dem Kunden, um seine wahre Identität und Bereitwilligkeit zu bestätigen, dem Kunden zu dienen:
5. * Nachricht H: Der Zeitstempel, der in Authenticator des Kunden plus 1, encrypted das Verwenden des Client-Server-Sitzungsschlüssels gefunden ist.
6. Der Kunde entschlüsselt die Bestätigung mit dem Client-Server-Sitzungsschlüssel und überprüft, ob der Zeitstempel richtig aktualisiert wird. Wenn so, dann kann der Kunde dem Server vertrauen und kann anfangen, Serviceanforderungen zum Server auszugeben.
7. Der Server stellt die gebetenen Dienstleistungen dem Kunden zur Verfügung.

Nachteile und Beschränkungen

• Einzelner Punkt des Misserfolgs: Es verlangt dauernde Verfügbarkeit eines Hauptservers. Wenn der Server von Kerberos unten ist, kann keiner darin loggen. Das kann durch das Verwenden vielfacher Server von Kerberos und Rückgriff-Beglaubigungsmechanismen gelindert werden.
• Kerberos hat strenge Zeitvoraussetzungen, was bedeutet, dass die Uhren der beteiligten Gastgeber innerhalb von konfigurierten Grenzen synchronisiert werden müssen. Die Karten haben eine Zeitverfügbarkeitsperiode, und wenn die Gastgeber-Uhr mit der Server-Uhr von Kerberos nicht synchronisiert wird, wird die Beglaubigung scheitern. Die Verzug-Konfiguration pro MIT verlangt, dass Zeiten zeigen, sind nicht mehr als fünf Minuten entfernt. In der Praxis werden Netzzeitprotokoll-Dämonen gewöhnlich verwendet, um die Gastgeber-Uhren synchronisiert zu halten.
• Das Regierungsprotokoll wird nicht standardisiert und unterscheidet sich zwischen Server-Durchführungen. Kennwort-Änderungen werden in RFC 3244 beschrieben.
• Da die ganze Beglaubigung von einem zentralisierten KDC kontrolliert wird, wird der Kompromiss dieser Beglaubigungsinfrastruktur einem Angreifer erlauben, jeden Benutzer zu imitieren.

Zusammenhängende Bitten um Anmerkungen

• RFC 4120 — Der Kerberos Netzbeglaubigungsdienst (V5)
• RFC 4537 — Kerberos Cryptosystem Verhandlungserweiterung
• RFC 4556 — Öffentliche Schlüsselgeheimschrift für die Anfängliche Beglaubigung in Kerberos (PKINIT)
• RFC 4752 — Der Kerberos V5 (GSSAPI) Einfache Beglaubigung und Sicherheitsschicht (SASL) Mechanismus
• RFC 6111 — Zusätzlicher Kerberos das Namengeben von Einschränkungen
• RFC 6112 — Anonymitätsunterstützung für Kerberos
• RFC 6113 — Ein Verallgemeinertes Fachwerk für die Kerberos Vorbeglaubigung
• RFC 6251 — Kerberos Version 5 über das Protokoll von Transport Layer Security (TLS) Verwendend

Siehe auch

• Einzelnes Zeichen - auf
• Identitätsmanagement
• SPNEGO
• S/Key
• Sichern Sie entferntes Kennwort-Protokoll (SRP)
• Allgemeine Sicherheitsdienstleistungsanwendungsprogramm-Schnittstelle (GSS-API)
• Host Identity Protocol (HIP)
• Liste des einzelnen Zeichens - auf Durchführungen

Zeichen

• Cisco Systeme

Links

• Wie Kerberos Beglaubigungsarbeiten
• Seite von Kerberos an MIT
• Kerberos Arbeitsgruppe an IETF
• Kerberos Konsortium an MIT
• Technische Dokumentation an MIT
• Verkäufer-Dokumentation und Spezifizierungen an MIT
• Kerberos wie - zu
• Die Kerberos häufig gestellten Fragen (letzt modifiziert am 8/18/2000)
• Shishi, eine freie Durchführung von Kerberos für das GNU-System
• Das Entwerfen eines Beglaubigungssystems: Ein Dialog in Vier Szenen. Humorvolles Spiel bezüglich, wie sich das Design von Kerberos entwickelt hat.
• Beschreibung von Kerberos 5 in der SPORE-Bibliothek
• Kerberos Beglaubigung in Windows Server 2003
• Kerberos Tutorenkurs
• Die Anmerkung von Novell Inc zur Vorgeschlagenen Ansiedlung zwischen Microsoft und dem Justizministerium - Microsoft bricht zweckmäßig Zwischenfunktionsfähigkeit von Kerberos
• Kerberos in FreeBSD
• Eingebettete Kerberos Durchführung durch TeamF1
• Heimdal, eine Durchführung von Kerberos 5