Kerberos (protocol)

MIT heeft Kerberos ontwikkeld om de netwerkdiensten van Project Athena te beschermen. Het protocol is genoemd naar het Griekse mythologische karakter Kerberos (of Cerberus), in de Griekse mythologie bekend als de monsterlijke driekoppige waakhond van Hades. Er bestaan verschillende versies van het protocol; versie 1-3 wordt alleen intern gebruikt bij MIT.

Steve Miller en Clifford Neuman, de primaire ontwerpers van Kerberos versie 4 (die het DES-encryptie-algoritme met 56-bits sleutels gebruikte), publiceerden die versie in 1989, hoewel ze het vooral voor Project Athena hadden bedoeld.

Versie 5, ontworpen door John Kohl en Clifford Neuman, verscheen in 1993 als RFC 1510 (in 2005 verouderd door RFC 4120), met de bedoeling de beperkingen en veiligheidsproblemen van versie 4 te overwinnen. Het MIT maakt een implementatie van Kerberos Versie 5 vrij beschikbaar, onder een softwarelicentie die vergelijkbaar is met die van de BSD-licentie.

Verschillende bedrijven gebruikten Kerberos Versie 5 in commerciële software, waaronder:

·         Microsoft's Windows 2000 en later gebruiken Kerberos als hun standaard authenticatiemethode.
Sommige Microsoft toevoegingen aan de Kerberos suite van protocollen zijn gedocumenteerd in RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols".
RFC 4757 documenteert Microsoft's gebruik van het RC4-cijfer.
Hoewel Microsoft het Kerberos protocol gebruikt, maakt het geen gebruik van de MIT software.[1].

·         Apple's Mac OS X maakt ook gebruik van Kerberos in zowel de client- als de serverversie.

·         Red Hat Linux versie 4 en later gebruikt Kerberos in zowel client als server versies.

In 2005 introduceerde de IETF Kerberos werkgroep een nieuwe bijgewerkte specificatie voor Kerberos Versie 5 [2]. updates omvatten:

·         "Encryptie- en controlespecificaties" (RFC 3961),

·         "Advanced EncryptionStandard (AES) Encryption for Kerberos 5" (RFC 3962),

·         Een nieuwe editie van de Kerberos Versie 5 specificatie "The Kerberos Network Authentication Service (V5)" (RFC 4120). Deze versie obsenteert RFC 1510, verduidelijkt aspecten van het protocol en het beoogde gebruik in een meer gedetailleerde duidelijke uitleg,

·         Een nieuwe editie van de GSS-API specificatie "Het Kerberos Versie 5 Generic Security Service Application Program Interface (GSS-API) Mechanisme: Versie 2." (RFC 4121).

In 2007 heeft MIT het Kerberos Consortium voor de voortzetting van de ontwikkeling opgericht.

Kerberos gebruikt als basis het Needham-Schroeder protocol. Het maakt gebruik van een vertrouwde derde partij authenticatie die bekend staat als "key distribution center (KDC)", dat bestaat uit twee logisch gescheiden delen: een Authenticatieserver (AS) en een Ticket Granting Server (TGS). Kerberos werkt op basis van "tickets" (genaamd Kerberos tickets) die dienen om de identiteit van gebruikers te bewijzen.

Kerberos database: Het sleuteldistributiecentrum (KDC) onderhoudt een database met geheime sleutels; elke entiteit op het netwerk - of het nu een client of een server is - deelt een geheime sleutel die alleen bekend is bij zichzelf en bij het KDC. Kennis van deze sleutel dient om de identiteit van elke entiteit te bewijzen. Voor de communicatie tussen twee entiteiten genereert het KDC een sessiesleutel die zij kunnen gebruiken om hun communicatie te beveiligen.

De term "Kerberos server" verwijst in het algemeen naar de KDC. Voor betrouwbaarheidsdoeleinden is het mogelijk om back-up KDC's te hebben. Deze worden "Kerberos slaveservers" genoemd. Alle slaven synchroniseren hun databases vanaf de master Kerberos server.

De term "Kerberized applicatie server" verwijst over het algemeen naar Kerberized programma's waarmee cliënten communiceren met behulp van Kerberos tickets voor authenticatie. De Kerberos telnet server is bijvoorbeeld een voorbeeld van een Kerberized applicatie server. Terwijl de term "Kerberized applicaties" wordt gebruikt om te verwijzen naar de clientzijde van de Kerberized applicatieserver , is de Kerberos telnet-client bijvoorbeeld een voorbeeld van een Kerberized applicatie

De veiligheid van het protocol is sterk afhankelijk van:

1. Deelnemers houden de tijd losjes gesynchroniseerd.
2. Een kortstondige verklaring van echtheid: de Kerberos tickets.

Vereenvoudigde beschrijving van het protocol

De volgende afkortingen worden gebruikt:

·         AS = Authenticatieserver

·         TGS = Ticket Granting Server

·         SS of Server = Service Server (Servergebruiker die zijn service aanvraagt, zoals een afdrukserver, een bestandsserver, enz...)

·         TGT = Ticket Granting Ticket (Kerberos ticket voor de TGS. Voorbereid door AS, vervolgens gebruikt om te praten met TGS).

In het kort: de klant authentiseert zich voor het AS met behulp van een langjarig gedeeld geheim en ontvangt een ticket van het AS. Later kan de klant dit ticket gebruiken om extra tickets voor SS te krijgen met behulp van hetzelfde gedeelde geheim. Deze tickets kunnen gebruikt worden om de authenticatie aan SS te bewijzen.

Het protocol in meer detail

Gebruiker Klantgebaseerde aanmeldingsstappen:

1. Een gebruiker voert een gebruikersnaam en wachtwoord in op de klantmachine.
2. De client voert een eenrichtingsfunctie (meestal een Hash-functie) uit op het ingevoerde wachtwoord, en dit wordt de geheime sleutel van de klant/gebruiker.

Klant Authenticatie Stappen:

1. De klant stuurt een cleartext-bericht naar het AS dat namens de gebruiker diensten aanvraagt.
   Voorbeeld bericht: "Gebruiker XYZ wil graag diensten aanvragen".
   Opmerking: Noch de geheime sleutel, noch het wachtwoord wordt naar het AS gestuurd.
2. Het AS controleert of de klant in zijn database staat. Als dat het geval is, stuurt het AS de volgende twee berichten terug naar de cliënt:
• Bericht A: Client/TGS Session Key gecodeerd met de geheime sleutel van de klant/gebruiker.
• Bericht B: TGT (met inbegrip van het client-ID, het adres van het clientnetwerk, de geldigheidsduur van het ticket en de Client/TGS-sessiesleutel) gecodeerd met behulp van de geheime sleutel van de TGS.
3. Zodra de klant de berichten A en B ontvangt, ontcijfert hij bericht A om de Client/TGS Session Key te verkrijgen. Deze sessiesleutel wordt gebruikt voor verdere communicatie met TGS. Op dit punt heeft de cliënt voldoende informatie om zich te authenticeren bij de TGS.
   Opmerking: De client kan bericht B niet ontcijferen, omdat het versleuteld is met de geheime sleutel van TGS.

Klantenservice Autorisatiestappen:

1. Bij het aanvragen van diensten stuurt de klant de volgende twee berichten naar de TGS:
• Bericht C: Samengesteld uit het TGT van bericht B en de ID van de gevraagde dienst.
• Bericht D: Authenticator (die bestaat uit de cliënt-ID en de tijdstempel), gecodeerd met de Client/TGS Session Key.
2. Bij ontvangst van de berichten C en D haalt de TGS bericht B uit bericht C. Het ontcijfert bericht B met behulp van de geheime sleutel van de TGS. Dit geeft het de Client/TGS Session Key. Met deze sleutel ontcijfert de TGS bericht D (Authenticator) en stuurt de volgende twee berichten naar de client:
• Bericht E: Client-to-Server-ticket (met inbegrip van het client-ID, het clientnetwerkadres, de geldigheidsperiode en de Client/Server-sessiesleutel), gecodeerd met behulp van de geheime SS-sleutel.
• Bericht F: Client/Server Session Key gecodeerd met de Client/TGS Session Key.

Klantenserviceaanvraag Stappen:

1. Bij ontvangst van de berichten E en F van TGS heeft de cliënt voldoende informatie om zich te authenticeren bij de SS. De client maakt verbinding met de SS en stuurt de volgende twee berichten:
• Bericht E: van de vorige stap (het Client-to-Server-ticket, gecodeerd met de geheime SS-sleutel).
• Bericht G: een nieuwe Authenticator, die de client-ID en tijdstempel bevat en gecodeerd is met de Client/Server Session Key.
2. De SS ontcijfert het ticket met behulp van zijn eigen geheime sleutel om de Client/Server Session Key op te halen. Met behulp van de sessiesleutel ontcijfert de SS de Authenticator en stuurt het volgende bericht naar de client om zijn ware identiteit en bereidheid om de client te dienen te bevestigen:
• Bericht H: de tijdstempel die in de Authenticator plus 1 van de client wordt gevonden, gecodeerd met de Client/Server Session Key.
3. De client decodeert de bevestiging met de Client/Server Session Key en controleert of het tijdstempel correct is bijgewerkt. Als dat het geval is, kan de client de server vertrouwen en kan hij beginnen met het uitgeven van serviceaanvragen aan de server.
4. De server levert de gevraagde diensten aan de klant.

• Enkelvoudig punt van mislukking: Het vereist continue beschikbaarheid van een centrale server. Als de Kerberos server uitgevallen is, kan niemand zich aanmelden. Dit kan worden opgelost door gebruik te maken van meerdere Kerberos servers en noodverificatiemechanismen.
• Kerberos vereist dat de klokken van alle betrokken hosts gesynchroniseerd worden. De tickets hebben een tijdbeschikbaarheidsperiode en als de hostklok niet gesynchroniseerd is met de Kerberos serverklok, zal de authenticatie mislukken. De standaardinstelling vereist dat de klok niet meer dan 10 minuten van elkaar verwijderd is. In de praktijk wordt Network Time Protocol (NTP) meestal gebruikt om alle hosts gesynchroniseerd te houden.
• Het beheerprotocol is niet gestandaardiseerd en verschilt tussen serverimplementaties. Wachtwoordwijzigingen worden beschreven in RFC 3244.
• Aangezien de geheime sleutels voor alle gebruikers op de centrale server zijn opgeslagen, zal een compromis van die server de geheime sleutels van alle gebruikers in gevaar brengen.
• Een gecompromitteerde klant zal het wachtwoord van de gebruiker in gevaar brengen.

• Identiteitsbeheer
• Veilig wachtwoord op afstand protocol (SRP)
• Algemene veiligheidsdiensten Applicatieprogramma-interface (GSS-API)