förklara som om jag är 5 år gammal: Kerberos – Vad är Kerberos, och varför ska jag bry mig?
även om detta ämne förmodligen inte kan förklaras för en 5-årig och förstås, är detta mitt försök att defragmentera dokumentation med vissa visuella hjälpmedel och smältbart språk.,
i ett nötskal
i grund och botten kommer Kerberos ner till just detta:
- ett protokoll för autentisering
- använder biljetter för att autentisera
- undviker att lagra lösenord lokalt eller skicka dem via internet
- innebär en betrodd 3: e part
- byggd på symmetrisk nyckelkryptografi
Du har en biljett-ditt identitetsbevis krypterat med en hemlig nyckel för den specifika tjänsten som begärs-på din lokala maskin (skapandet av en biljett beskrivs nedan); så länge det är giltigt kan du komma åt den begärda tjänsten som ligger inom en Kerberos rike.,
vanligtvis används detta inom företag / interna miljöer. Kanske vill du komma åt din interna Lönelista webbplats för att granska vilken liten bonus din chef har gett dig. I stället för att skriva in dina användaruppgifter/lösenordsuppgifter används din biljett (cachad på ditt system) för att autentisera vilket möjliggör enkel inloggning.
din biljett uppdateras när du loggar in på din dator, eller när dukinit USER I din terminal.
För trivia-älskande folk kommer Kerberos namn från grekisk mytologi, Hades trehövdade vakthund., Det är ganska passande eftersom det tar en tredje part (ett Nyckeldistributionscenter) att autentisera mellan en klient och en tjänst eller värdmaskin.
Kerberos Realm
administratörer skapar realms – Kerberos realms – som kommer att omfatta allt som är tillgängligt för åtkomst. Beviljas, du kanske inte har tillgång till vissa tjänster eller värddatorer som definieras i policyhantering-utvecklare bör inte få tillgång till något finansrelaterat, sådant. Men en värld definierar vad Kerberos hanterar när det gäller vem som kan komma åt vad.,
din maskin, klienten, bor inom detta område, liksom den tjänst eller värd du vill begära och Nyckeldistributionscentret, KDC (nej, inte KGB, även om jag alltid tänker på det också). I följande exempel separerar jag autentiseringsservern och Biljettgivningsservern, men båda ligger inom KDC.
för att hålla dig på baksidan av ditt sinne
Du kanske vill komma tillbaka hit efter att du läst igenom gritty detaljer om hur exemplet fungerar.,
När du begär åtkomst till en tjänst eller värd sker tre interaktioner mellan dig och:
- autentiseringsservern
- den biljett som beviljar servern
- den tjänst eller värddator som du vill ha tillgång till.
andra viktiga punkter:
- med varje interaktion får du två meddelanden. Varje meddelande är en som du kan dekryptera, och en som du inte kan.
- tjänsten eller maskinen du begär åtkomst till kommunicerar aldrig direkt med KDC.,
- KDC lagrar alla hemliga nycklar för användarmaskiner och tjänster i sin databas.
- hemliga nycklar är lösenord plus ett salt som hashed – hashalgoritmen väljs under implementeringen av Kerberos-installationen. För tjänster eller värddatorer finns det inga lösenord (vem skulle ange det). En nyckel genereras faktiskt av en administratör under första installationen och memoreras på tjänsten/värddatorn.
- återigen lagras dessa hemliga nycklar i KDC-databasen; minns Kerberos förlitan på symmetrisk nyckelkryptografi.,
- KDC själv är krypterad med en huvudnyckel för att lägga till ett lager av svårigheter från att stjäla nycklar från databasen.
- Det finns Kerberos konfigurationer och implementeringar som använder kryptering med öppen nyckel istället för symmetrisk nyckelkryptering.
en åt sidan: ordern för meddelandena och deras innehåll som diskuteras här återspeglar inte den ordning i vilken de skickas över TCP eller UDP.
exemplet nedan beskriver vad som händer när du begär något från en intern HTTP – tjänst-liknande information om löner inom ditt företags intranät.,
du och autentiseringsservern
du vill komma åt en HTTP-tjänst, men först måste du presentera dig för autentiseringsservern. Logga in på din dator, ellerkinit USERNAME, initierar den introduktionen via en klartext begäran om en biljett beviljande biljett (TGT)., Meddelandet plaintext innehåller:
- ditt namn/ID
- namnet/ID för den begärda tjänsten (i det här fallet är tjänsten den Ticket Granting Server),
- din nätverksadress (kan vara en lista över IP-adresser för flera maskiner, eller kan vara null om du vill använda på vilken maskin som helst) och
- begärd livstid för TGT: s giltighet,
och skickas till autentiseringsservern.
autentiseringsservern kontrollerar om du är i KDC-databasen. Denna kontroll är bara för att se om du finns; inga referenser är markerade.,
om det inte finns några fel (t.ex. användaren inte hittas), kommer det slumpmässigt att generera en nyckel som kallas en sessionsnyckel för användning mellan dig och Ticket Granting Server (TGS).
autentiseringsservern skickar sedan två meddelanden tillbaka till dig., Ett meddelande är TGT som innehåller:
- ditt namn/ID,
- TGS namn/ID,
- tidsstämpel,
- din nätverksadress (kan vara en lista över IP-adresser för flera maskiner, eller kan vara null om du vill använda på vilken maskin som helst)
- livslängd för TGT (kan vara vad du ursprungligen begärde, lägre om du eller TGS hemliga nycklar är på väg att löpa ut, eller en annan gräns som genomfördes under Kerberos Setup), och
- TGS sessionsnyckel,
och krypteras med TGS Secret-tangenten ., Det andra meddelandet innehåller:
- TGS-namnet/ID,
- tidsstämpel,
- livstid (samma som ovan) och
- TGS-sessionsnyckel
och krypteras med din klient hemlig nyckel. Observera att TGS-sessionsnyckeln är den delade nyckeln mellan dig och TGS.
din klient hemlig nyckel bestäms genom att be dig om ditt lösenord, lägga till ett salt (består av) och hashing det hela. Nu kan du använda den för att dekryptera det andra meddelandet för att få TGS-sessionsnyckeln., Om lösenordet är felaktigt kan du inte dekryptera meddelandet. Observera att detta är det steg där lösenordet du anger är implicit validerat.
Du kan dock inte dekryptera TGT eftersom du inte känner till TGS Secret-tangenten. Den krypterade TGT lagras i din referens cache.
du och Ticket Granting Server
vid denna tidpunkt har du TGT som du inte kan läsa eftersom du inte har TGS Secret-nyckeln för att dekryptera den. Du har dock TGS-sessionsnyckeln.,
det är nu din tur att skicka två meddelanden. Du förbereder först autentiseraren, krypterad med TGS-Sessionstangenten, som innehåller:
- ditt namn/ID och
- tidsstämpel.
du skickar ett okrypterat meddelande som innehåller:
- det begärda HTTP-tjänstenamnet/ID du vill ha tillgång till, och
- biljettens livstid för HTTP-tjänsten,
tillsammans med den krypterade autentiseraren och TGT till Biljettgivningsservern.
den biljett som beviljar servern kontrollerar först KDC-databasen för att se om HTTP-tjänsten finns.,
om så är fallet dekrypterar TGT med sin hemliga nyckel . Eftersom den nu okrypterade TGT innehåller TGS-sessionsnyckeln kan TGS dekryptera autentiseraren du skickade.,på grund av:
- jämför ditt klient-ID från autentiseraren till TGT
- jämför tidsstämpeln från autentiseraren till TGT (typisk Kerberos-system tolerans av skillnad är 2 minuter, men kan konfigureras på annat sätt)
- kontrollera om TGT har löpt ut (livstidselementet),
- kontrollera att autentiseraren inte redan finns i TGS cache (för att undvika replay-attacker) och
- kontrollera om TGT har löpt ut (livstidselementet),
- kontrollera att autentiseraren inte redan finns i >
- Om nätverksadressen i den ursprungliga begäran inte är null, jämför källans IP-adress med din nätverksadress (eller i den begärda listan) i tgt.,
den biljett som beviljar servern genererar sedan slumpmässigt HTTP-Tjänstesessionstangenten och förbereder HTTP-tjänstebiljetten för dig som innehåller:
- ditt namn/ID,
- HTTP-tjänstens namn/ID,
- din nätverksadress (kan vara en lista över IP-adresser för flera maskiner, eller kan vara null om du vill använda på vilken maskin som helst),
- tidsstämpel,
- livstid för biljettens giltighet och
- http service session key,
och krypterar den med HTTP service secret key.
sedan skickar TGS dig två meddelanden., Den ena är den krypterade HTTP-Servicebiljetten; den andra innehåller:
- HTTP-tjänstens namn / ID,
- tidsstämpel,
- giltighetstiden för biljetten och
- HTTP-Tjänstesessionsnyckel,
som är krypterad med TGS-sessionsnyckeln.
din maskin dekrypterar det senare meddelandet med TGS-Sessionstangenten som den cachade tidigare för att hämta HTTP-Sessionstangenten.
din maskin kan dock inte dekryptera HTTP-Tjänstebiljetten eftersom den är krypterad med HTTP-tjänstens hemliga nyckel.,
du och HTTP-tjänsten
för att nu komma åt HTTP-tjänsten, förbereder din maskin ett annat Autentiseringsmeddelande som innehåller:
- ditt namn/ID,
- tidsstämpel,
och krypteras med HTTP Servicesessionstangenten. Din maskin skickar sedan autentiseraren och den fortfarande krypterade HTTP-Servicebiljetten som tas emot från TGS.
HTTP-tjänsten dekrypterar sedan biljetten med sin hemliga nyckel för att få HTTP-Tjänstesessionstangenten., Den använder sedan den sessionsnyckeln för att dekryptera Autentiseringsmeddelandet du skickade.,li>
HTTP-tjänsten skickar sedan ett Autentiseringsmeddelande som innehåller dess ID och tidsstämpel för att bekräfta sin identitet för dig och krypteras med HTTP-tjänsten sessionsnyckel.
din maskin läser Autentiseringsmeddelandet genom att dekryptera med den cachade HTTP-Sessionstangenten och vet att den måste ta emot ett meddelande med HTTP-tjänstens ID och tidsstämpel.
och nu har du autentiserats för att använda HTTP-tjänsten., Framtida förfrågningar använder cachad HTTP-Servicebiljett, så länge den inte har löpt ut enligt definitionen i lifetime-attributet.
medan jag kommer att skriva om detta senare måste HTTP-tjänsten själv kunna stödja Kerberos. Du måste också ha en webbläsare som stöder SPNEGO / förhandla.,
läs kanske de punkter som tidigare skisserats; kolla in den här eller den här aktuella implementeringen, särskilt den som jag får betalt för att arbeta som kommunicerar med den här populära implementeringen; eller granska en handledning, resursguide, go-to-videon som skickades till mig när jag började lära mig om Kerberos eller RFC själv.
ovanstående bilder gjordes med Keynote med ikoner som används från font awesome och glyphicons, och finns på slideshare.