Kerberos (protocol)
Kerberos is een standaard authenticatie protocol dat ervoor zorgt dat gebruikers van een netwerk zich op een veilige manier kunnen aanmelden en hun identiteit kunnen bewijzen, zonder zich telkens opnieuw te moeten aanmelden. Kerberos maakt een beperkte vorm van Single Sign-on mogelijk.
Het MIT ontwikkelde Kerberos als beveiliging voor hun Project Athene, en vernoemde het naar het Griekse mythologische karakter Kerberos, een monsterlijke driekoppige hond die de toegang tot Hades bewaakte. Tot ongeveer het jaar 2000 was Kerberos als strategisch belangrijke technologie onderhevig aan de Amerikaanse exportrestricties.
De Kerberos functie betekent dat een Kerberos server aan een ingelogde gebruiker een Ticket toekent. Dit ticket blijft gedurende de hele sessie geldig en wordt vertrouwd door andere servers die het protocol kennen. Als de gebruiker uitlogt, wordt de sessie afgebroken en is het ticket niet langer geldig.
Kerberos is beschikbaar op vrijwel alle computer platformen, van Unix en Linux, tot Windows en Mac OS X. Ook andere systemen, zoals het Oracle database management systeem, kunnen overweg met de tickets.
Inhoud |
[bewerk] Werking
De driekoppige hond Kerberos uit de griekse mythen heeft niet voor niets zijn naam geleend aan dit protocol. In dit protocol spelen drie "hoofden" een belangrijke en onlosmakelijk verbonden rol: de client, de service en een vertrouwde derde partij, de Key Distribution Center (KDC).
Op het eerste gezicht is Kerberos een ingewikkeld protocol, maar deze opzet is bewust gekozen om de overhead voor alle partijen zoveel mogelijk te minimaliseren.
Eigenschappen van het protocol zijn:
- Wederzijdse authenticatie tussen client en server
- Minimalisering van belasting van alle partijen
- Wachtwoorden worden nooit uitgewisseld
- Naspelen van de authenticatie is niet mogelijk
[bewerk] Globale werking
De gebruiker gebruikt zijn gebruikersnaam en wachtwoord om te bewijzen wie hij is. De KDC geeft op basis van die gegevens een soort paspoort af, de Ticket Granting Ticket. Met dat Ticket Granting Ticket (of TGT) vraagt de Kerberos-client toegang aan voor services bij de KDC. Op basis van dit TGT geeft de KDC een zgn. Session Ticket voor de service af. Met dat session ticket benadert de client vervolgens de services om toegang te verkrijgen. Voor iedere service, die een client wil benaderen, vraagt deze zo'n session ticket aan. Zowel de TGT als de session ticket blijven lang geldig en kunnen meerdere keren worden gebruikt om de sessies op te bouwen. Dit minimaliseert de belasting van de KDC en de service.
[bewerk] Meer in detail
[bewerk] Vaststellen van de identiteit
Voordat een gebruiker toegang krijgt tot bepaalde services, moet hij eerst bewijzen wie hij is. De gebruikersnaam en wachtwoord spelen hierin een belangrijke rol. De encryptie wordt gedaan met een gedeelde sleutel, de hash van het wachtwoord.
1. Een gebruiker geeft zijn gebruikernaam en wachtwoord aan de Kerberos client. Dit wachtwoord hoort alleen aan de gebruiker en aan de KDC bekend te zijn.
2. De client maakt een hash van het wachtwoord, de long-term key
3. De client versleutelt het actuele tijdstip met deze long-term key en stuurt dit samen met de gebruikersnaam naar de Authentication Server, een onderdeel van de KDC.
4. De authentication server kijkt vervolgens in zijn database wat de wachtwoord-hash is die bij de opgegeven gebruikersnaam hoort. (de meeste authenticatiesystemen slaan nooit wachtwoorden op maar alleen hashes van die wachtwoorden)
5. Met behulp van deze hash (dus de long-term key van de gebruiker) wordt het bericht van de client ontcijferd. Dit bericht was het actuele tijdstip op de client. Als het ontcijferde bericht (binnen bepaalde grenzen) overeenkomt met de actuele tijd op de server kan worden aangenomen dat het ingevoerde wachtwoord correct was. De gebruiker is wie hij zegt dat hij is.
6. De authentication server haalt vervolgens de tijd uit het bericht versleutelt dat wederom met de long-term key en stuurt dat naar de client
7. De client gebruikt vervolgens zijn long-term key om dit bericht weer te ontcijferen. Als het ontcijferde bericht inderdaad het eerder versleutelde tijdstip was, dan kende de authentication server dus blijkbaar ook die hash en moet dit dus de KDC geweest zijn. Immers alleen de gebruiker en de KDC horen het wachtwoord (of de hash ervan) te kennen. De authenticatie is nu wederzijds.
Merk het volgende op:
- Het wachtwoord of de hash ervan (oftewel de long-term key) worden nooit uitgewisseld. Zij worden slechts gebruikt om een bericht te versleutelen.
- Dit bericht is de tijd. Deze moeten (binnen redelijke grenzen) dus gelijk lopen op de authentication server en de client, anders kan het nooit gecontroleerd worden.
- In theorie is het mogelijk dat iemand, die meeluistert, het allereerste bericht van de client (de tijd die versleuteld is door de long-term key) onderschept en deze op zijn beurt (nogmaals) gaat aanbieden aan de authentication server. Om dit te voorkoment houdt de authentication server bij wat het laatste tijdstip is geweest waarop zo'n bericht is gestuurd. Alle volgende authenticatie-pogingen moeten dus later komen. Naspelen is dus niet mogelijk.
[bewerk] Opzetten van een sessie
Voor het opzetten van de sessie worden twee sessie-sleutels gebruikt, één voor de client en voor de server. Deze sessie-sleutels worden gegenereerd door de Key Distribution Center. Dat gaat als volgt:
8. De client vraagt aan de KDC sessiesleutels voor een bepaalde service
9. De KDC genereert een sessiesleutel en kopieert deze.
10 De KDC versleutelt de ene kopie met de long-term key van de client. De andere wordt voorzien van wat informatie over de client en wordt versleuteld met de long-term key van de service. (Deze staat immers ook in de account database van de KDC). De sessiesleutel voor de server tezamen met de informatie over de client wordt als één geheel versleuteld en wordt session ticket genoemd.
11. De KDC stuurt dit session ticket aan de client.
12. De client ontcijfert het client-deel mijn zijn eigen long-term key (de wachtwoord-hash). De eigen sessiesleutel wordt samen met het session ticket opgeslagen.
13. Daarna wordt de session ticket samen met een zgn. authenticator (de actuele tijd op de client, samen met wat informatie over de client) verstuurd naar de service. Die authenticator wordt versleuteld met de sessiesleutel.
14. De service gebruikt zijn eigen long-term key om het session ticket te ontcijferen. Zo komt de service te weten wat de sessiesleutel is en met wie die sessie opgezet wordt.
15. Met behulp van de sessiesleutel wordt de authenticator ontcijferd Als het goed is, komt de client-informatie overeen met wat in het session ticket stond. Bovendien klopt het tijdstip dat ook versleuteld was, met het tijdstip op de computer waarop de service draait. De client heeft nu bewezen wie hij is. De informatie die hij aan de service gegeven heeft, klopt met de informatie die de KDC in het ticket gezet heeft. Dat ticket was bovendien versleuteld met een sleutel die alleen de KDC maar kon kennen. Dat betekent dat de client ook inderdaad door een vertrouwde derde partij is geauthenticeerd.
16. De server gebruikt nu de sessiesleutel om het uit de authenticator gehaalde tijdstip weer te versleutelen en naar de client te sturen.
17. De client ontvangt dit bericht en ontsleutelt dat met de sessiesleutel. Als het resultaat overeenkomt met het tijdstip dat naar de service gestuurd is, heeft deze de sessiesleutel met succes uit het session ticket kunnen halen. Daarvoor was een sleutel nodig die alleen die service en de KDC kenden. De service heeft nu ook aan de client bewezen te zijn wie hij zegt te zijn.
Nu client en service aan elkaar hebben aangetoond wie zij zijn, kan het autoriseren beginnen. Hier wordt bekeken of de client ook inderdaad rechten heeft om de service te benaderen. Dit valt echter buiten het bestek van het Kerberos-protocol dat primair bedoeld is om een gebruiker en service aan elkaar te identificeren.
[bewerk] Ticket Granting Ticket.
Een bijzonder session ticket is het Ticket Granting Ticket. Dit ticket wordt gegenereerd door de KDC om de client in staat te stellen session tickets aan te vragen voor andere services. Daardoor is het niet nodig om voor ieder nieuw session ticket opnieuw gebruikersnaam en wachtwoord in te voeren.
