Explain like I ‘ m 5 years old: Kerberos – what is Kerberos, and why should I care?
hoewel dit onderwerp waarschijnlijk niet uitgelegd kan worden aan een 5-jarige en begrepen kan worden, is dit mijn poging om documentatie te defragmenteren met wat visuele hulpmiddelen en verteerbare taal.,
In een notendop
in feite, Kerberos komt er op neer om gewoon dit:
- een protocol voor authenticatie
- toepassingen tickets te verifiëren
- voorkomt de opslag van wachtwoorden lokaal of sturen deze via het internet
- het gaat om een vertrouwde 3rd-party
- gebouwd op symmetrische sleutel cryptografie
heb Je een ticket voor het bewijs van de identiteit gecodeerd met een codeersleutel voor de specifieke dienst – op uw lokale machine (creatie van een ticket is hieronder beschreven); zo lang het geldig is, kunt u toegang krijgen tot de gevraagde dienst die binnen een Kerberos-realm.,
Dit wordt meestal gebruikt in zakelijke / interne omgevingen. Misschien wilt u toegang tot uw interne payroll site om te beoordelen wat kleine bonus je baas heeft gegeven. In plaats van het opnieuw invoeren van uw gebruiker/wachtwoord referenties, uw ticket (in de cache op uw systeem) wordt gebruikt om te verifiëren waardoor single sign-on.
uw ticket wordt ververst wanneer u zich aanmeldt op uw computer, of wanneer u kinit USER binnen uw terminal.Kerberos ‘ naam komt uit de Griekse mythologie, de driekoppige waakhond van Hades., Het is vrij passend omdat er een derde partij (Een Sleutel distributiecentrum) nodig is om te authenticeren tussen een client en een service of host machine.
Kerberos Realm
Admins create realms – Kerberos realms – that will encryptie all that is available to access. Toegegeven, je mag geen toegang hebben tot bepaalde diensten of host machines die is gedefinieerd binnen het beleid management – ontwikkelaars moeten geen toegang tot iets financiën gerelateerde, dingen als dat. Maar een rijk definieert wat Kerberos beheert in termen van wie toegang heeft tot wat.,
uw machine, de Client, Woont binnen dit domein, evenals de service of host die u wilt aanvragen en het Key Distribution Center, KDC (nee, niet de KGB, hoewel ik daar ook altijd aan denk). In het volgende voorbeeld scheid ik de authenticatieserver en de Ticketverleningsserver, maar beide bevinden zich binnen de KDC.
om in je achterhoofd te houden
wilt u misschien hier terugkomen nadat u de stenige details hebt gelezen over hoe het voorbeeld werkt.,
bij het aanvragen van toegang tot een service of host vinden drie interacties plaats tussen u en:
- de authenticatieserver
- de Ticketverlenende Server
- de Service of hostmachine waartoe u toegang wilt.
andere belangrijke punten:
- bij elke interactie ontvangt u twee berichten. Elk bericht is er een die je kunt decoderen, en een die je niet kunt.
- de service of machine waarvoor u toegang vraagt, communiceert nooit direct met de KDC.,
- de KDC slaat alle geheime sleutels voor gebruikersmachines en services op in zijn database.
- geheime sleutels zijn wachtwoorden plus een Salt die gehasht zijn – het hash algoritme wordt gekozen tijdens de implementatie van de Kerberos setup. Voor services of hostmachines zijn er geen wachtwoorden (wie zou het invoeren). Een sleutel wordt eigenlijk gegenereerd door een admin tijdens de eerste setup en opgeslagen op de service/host machine.
- nogmaals, deze geheime sleutels worden allemaal opgeslagen in de KDC database; roep de afhankelijkheid van Kerberos op van symmetrische-sleutel cryptografie.,
- de KDC zelf is versleuteld met een hoofdsleutel om een moeilijkheidsgraad toe te voegen bij het stelen van sleutels uit de database.
- Er zijn Kerberos-configuraties en-implementaties die cryptografie met publieke sleutels gebruiken in plaats van symmetrische versleuteling met sleutels.
an terzijde: de volgorde van de berichten en hun inhoud die hier wordt besproken, geeft niet de volgorde weer waarin ze via TCP of UDP worden verzonden.
het voorbeeld hieronder beschrijft wat er gebeurt als u iets aanvraagt van een interne HTTP – Service-achtige informatie met betrekking tot payroll binnen uw bedrijfsintranet.,
u en de authenticatieserver
u wilt toegang krijgen tot een HTTP-Service, maar eerst moet u uzelf voorstellen aan de authenticatieserver. Inloggen op uw computer, of kinit USERNAME, start die introductie via een verzoek in platte tekst voor een Ticket Grant Ticket (TGT)., Het platte tekstbericht bevat:
- uw naam / ID
- de naam/ID van de gevraagde service (in dit geval is service de Ticketverlenende Server),
- uw netwerkadres (kan een lijst zijn met IP-adressen voor meerdere machines, of kan null zijn als u deze op een machine wilt gebruiken), en
- gevraagde levensduur voor de geldigheid van de TGT,
en wordt verzonden naar de authenticatieserver.
de authenticatieserver zal controleren of u zich in de KDC-database bevindt. Deze controle is alleen om te zien of u bestaat; er worden geen referenties gecontroleerd.,
als er geen fouten zijn (bijvoorbeeld de gebruiker wordt niet gevonden), genereert het willekeurig een sleutel genaamd een sessiesleutel voor gebruik tussen u en de Ticketverlenende Server (TGS).
de authenticatieserver zal dan twee berichten naar u terugsturen., Een bericht is de TGT die bevat:
- uw naam/ID,
- de TGS naam/ID,
- timestamp
- je netwerk adres (kan een lijst van IP-adressen voor meerdere machines, of null als het willen gebruiken van een machine)
- de levensduur van de TGT (zou kunnen zijn wat je in eerste instantie gevraagd, lager als u of de TGS ‘ s geheime sleutels zijn verlopen, of een andere limiet, die werd uitgevoerd tijdens de Kerberos-setup), en
- TGS Sessie Sleutel
en dat is gecodeerd met de TGS Geheime Sleutel ., Het andere bericht bevat:
- de TGS-naam / ID,
- tijdstempel,
- levensduur (hetzelfde als hierboven), en
- TGS-sessiesleutel
en is versleuteld met uw Client Secret Key. Merk op dat de TGS-sessiesleutel de gedeelde sleutel is tussen u en de TGS.
uw Client geheime sleutel wordt bepaald door u te vragen om uw wachtwoord, het toevoegen van een salt (bestaande uit ) en hashing het geheel. Nu kunt u het gebruiken voor het decoderen van het tweede bericht om de TGS-sessiesleutel te verkrijgen., Als het wachtwoord onjuist is, dan zul je niet in staat zijn om het bericht te decoderen. Houd er rekening mee dat dit de stap is waarin het wachtwoord dat u invoert impliciet wordt gevalideerd.
u kunt echter de TGT niet decoderen omdat u de TGS-geheime sleutel niet kent. De versleutelde TGT wordt opgeslagen in uw credential cache.
u en de Ticketverlenende Server
Op dit moment hebt u de TGT die u niet kunt lezen omdat u de TGS geheime sleutel niet hebt om het te ontcijferen. U heeft echter wel de TGS-sessiesleutel.,
Het is nu uw beurt om twee berichten te versturen. U bereidt eerst de Authenticator voor, versleuteld met de TGS-sessiesleutel, met:
- uw naam/ID, en
- tijdstempel.
u verzendt een niet-versleuteld bericht dat het volgende bevat:
- de gevraagde HTTP-servicenaam/ – ID waartoe u toegang wilt, en
- levensduur van het Ticket voor de HTTP-Service,
samen met de versleutelde Authenticator en TGT naar de Ticketverlenende Server.
De Ticketverlenende Server controleert eerst de KDC-database om te zien of de HTTP-Service bestaat.,
als dat zo is, decodeert de TGS de TGT met zijn geheime sleutel . Omdat de nu niet-versleutelde TGT de TGS sessiesleutel bevat, kan de TGS de Authenticator decoderen die u hebt verzonden.,vanwege:
- vergelijk uw client-ID van de Authenticator met die van de TGT
- vergelijk de tijdstempel van de Authenticator met die van de TGT (typische Kerberos-systeemtolerantie van verschil is 2 minuten, maar kan anders worden geconfigureerd)
- controleer of de TGT verlopen is (het lifetime-element),
- controleer of de Authenticator niet al in de TGS-cache zit (om replay-aanvallen te vermijden), en
- als het netwerkadres in de oorspronkelijke aanvraag niet NULL is, vergelijkt u het IP-adres van de bron met uw netwerkadres (of in de gevraagde lijst) binnen de TGT.,
De Ticket Granting Server dan willekeurig genereert de HTTP-Service Sessie Sleutel, en bereidt de HTTP-Service ticket voor je dat bevat:
- uw naam/ID,
- HTTP-Service naam/ID,
- je netwerk adres (kan een lijst van IP-adressen voor meerdere machines, of null als het willen gebruiken van een machine),
- timestamp
- de levensduur van de geldigheid van het ticket en
- HTTP-Service Session Key,
en versleutelt met de HTTP-Service Geheime Sleutel.
dan stuurt de TGS u twee berichten., Het ene is het versleutelde HTTP-serviceticket; het andere bevat:
- HTTP-servicenaam / – ID,
- tijdstempel,
- levensduur van de geldigheid van het ticket, en
- HTTP-Servicesessiesleutel,
die is versleuteld met de TGS-sessiesleutel.
uw machine decodeert het laatste bericht met de TGS-sessiesleutel die eerder in de cache is opgeslagen om de HTTP-Service sessiesleutel te verkrijgen.
uw machine kan echter het HTTP-serviceticket niet decoderen omdat het versleuteld is met de HTTP Service Secret Key.,
u en de HTTP-Service
om nu toegang te krijgen tot de HTTP-Service, bereidt uw machine een ander verificatiebericht voor dat bevat:
- uw naam/ID,
- tijdstempel,
en is versleuteld met de HTTP-Service sessiesleutel. Uw machine stuurt vervolgens de Authenticator en het nog steeds versleutelde HTTP-serviceticket van de TGS.
de HTTP-Service decodeert vervolgens het Ticket met zijn geheime sleutel om de HTTP-Service sessiesleutel te verkrijgen., Het gebruikt dan die sessie sleutel om het Authenticator bericht dat u verzonden decoderen.,es uw client-ID van de Authenticator naar die van het Ticket,
de HTTP-Service stuurt vervolgens een Authenticatorbericht met zijn ID en tijdstempel om zijn identiteit aan u te bevestigen en wordt versleuteld met de HTTP-Service sessiesleutel.
uw machine leest het verificatiebericht door te decoderen met de HTTP Service sessiesleutel in de cache, en weet dat het een bericht moet ontvangen met de ID en tijdstempel van de HTTP Service.
en nu bent u geverifieerd om de HTTP-Service te gebruiken., Toekomstige aanvragen gebruiken het HTTP-serviceticket in de cache, zolang het niet is verlopen zoals gedefinieerd in het lifetime-attribuut.
hoewel ik hier later op zal schrijven, moet de HTTP-Service zelf Kerberos kunnen ondersteunen. Ook, moet u ook een browser die SPNEGO ondersteunt/onderhandelen.,
misschien de eerder geschetste punten opnieuw lezen; bekijk deze of deze huidige implementatie, vooral die waarop ik betaald word om te werken die communiceert met deze populaire implementatie; of bekijk een tutorial, resource guide, de go-to video die naar mij werd gestuurd toen ik begon te leren over Kerberos, of de RFC zelf.
de bovenstaande afbeeldingen zijn weergegeven met Keynote met pictogrammen die worden gebruikt van font awesome en glyphicons, en zijn beschikbaar op slideshare.