Kerberos

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 21 mars 2020; verifiering kräver 21 redigeringar .

Kerberos /kɛərbərəs/ är ett nätverksautentiseringsprotokoll som erbjuder en mekanism för ömsesidig autentisering av en klient och server innan en anslutning upprättas mellan dem. Kerberos utför autentisering som en betrodd tredje parts autentiseringstjänst med hjälp av en kryptografisk delad hemlighet, förutsatt att paket som färdas över ett osäkert nätverk kan fångas upp, modifieras och användas av en angripare. Kerberos bygger på symmetrisk nyckelkryptografi och kräver ett nyckeldistributionscenter. Kerberos-tillägg kan tillhandahålla användning av publik nyckelkryptering i vissa autentiseringssteg.

Skapande historia

Den första versionen av Kerberos-protokollet skapades 1983 vid Massachusetts Institute of Technology (MIT) som en del av Athena-projektet.. Huvudmålet med projektet var att ta fram en plan för införandet av datorer i MITs utbildningsprocess och tillhörande programvara. Projektet var lärorikt, men slutresultatet innehöll flera mjukvaruprodukter som fortfarande används flitigt idag (som X Window System ). Detta protokoll har blivit allmänt tillgängligt sedan version 4.

Grundläggande begrepp

Låt oss skissera grundkonceptet för Kerberos-protokollet. Anta att det finns två personer som känner till samma hemlighet, bara kända för dessa två. Då kan vem som helst av dem lätt vara säker på att han har att göra med sin partner. För att göra detta måste han bara kontrollera om hans samtalspartner känner till den delade hemligheten.

Exempel.

Punkt 1. Överenskommelse om lösenord. Låt Alice kommunicera med Bob. I det här fallet använder Bob informationen endast när han är säker på att informationen kommer från Alice. För att undvika förfalskning kom de sinsemellan överens om ett lösenord som bara de två känner till. När Bob får ett meddelande kan han dra slutsatsen från brevet om hans samtalspartner känner till lösenordet. Om Bobs samtalspartner känner till lösenordet kan det hävdas att hans samtalspartner är Alice.

Punkt 2. Förekomsten av ett problem med lösenordsöverföring. Låt oss nu bestämma hur vi ska visa Alice och Bob kunskapen om lösenordet. Naturligtvis kan du helt enkelt inkludera lösenordet i e-postmeddelandets brödtext. Till exempel: "Hej Bob. Vårt lösenord. Om bara Bob och Alice var säkra på att ingen läser deras brev, så skulle den här metoden kunna användas. Men tyvärr sänds posten över ett nätverk där andra användare arbetar, bland vilka det finns en nyfiken Eva. Eve gav sig själv uppgiften att ta reda på lösenordet, som bara Bob och Alice känner till, som de utbyter meddelanden med varandra med. Nu är det helt klart att du inte kan ange lösenordet bara i brevets brödtext. Det betyder att du inte kan prata öppet om lösenordet, men samtidigt måste du meddela samtalspartnern att du känner till lösenordet.

Punkt 3. Lösa problemet med lösenordsöverföring. Kerberos-protokollet löser problemet med lösenordsöverföring med hjälp av hemlig nyckelkryptering. Istället för att berätta för varandra ett lösenord, utbyter deltagarna i en kommunikationssession en kryptografisk nyckel, vars kunskap bekräftar samtalspartnerns identitet. Men för att en sådan teknik ska vara möjlig är det nödvändigt att den delade nyckeln är symmetrisk , det vill säga nyckeln måste tillhandahålla både kryptering och dekryptering av meddelandet.

Punkt 4. Problemet med lösenordsutbyte. Det finns ett viktigt problem när man använder enkla protokoll som det som beskrivs ovan. När det gäller Bob och Alice måste du förstå hur de kommer överens om en hemlig nyckel för att korrespondera med varandra. Naturligtvis kan folk träffas och komma överens, men maskiner deltar också i nätverksförhandlingar. Om Alice förstås som ett klientprogram, och Bob är en tjänst på en nätverksserver, så kan de inte träffas på något sätt. Problemet är att när en klient behöver skicka ett meddelande till flera servrar, måste den i detta fall skaffa en separat nyckel för varje server. Och sedan kommer servern att behöva lika många hemliga nycklar som den har klienter. Behovet av att lagra så många nycklar på varje dator utgör en risk för hela säkerhetssystemet.

Punkt 5. Lösa problemet med att byta lösenord. För att lösa dessa problem utvecklade Athena-projektet ett speciellt protokoll - Kerberos. I analogi med den antika grekiska mytologin var detta protokoll uppkallat efter den trehövdade hunden som skyddade utgången från Hades rike - Cerberus , eller mer exakt - Cerberus. De tre cheferna för Cerberus i protokollet motsvarar tre deltagare i säker kommunikation: en klient, en server och en pålitlig mellanhand mellan dem. Rollen som mellanhand här spelas av Key Distribution Center, KDC.

Key Distribution Center KDC (eller TGS - biljett- eller behörighetsserver)

Ett nyckeldistributionscenter (KDC) är en tjänst som körs på en fysiskt säker server. Centret för en databas med information om alla nätverksklienters konton. Tillsammans med information om varje abonnent lagrar nyckeldistributionscentraldatabasen en kryptografisk nyckel som endast är känd för denna abonnent och centraltjänsten. Denna nyckel används för att koppla klienten till centret.

Klient till server via KDC

Om klienten vill kontakta servern skickar han ett meddelande till nyckeldistributionscentralen. Centret skickar till varje sessionsdeltagare kopior av sessionsnyckeln som är giltig under en kort tidsperiod. Syftet med dessa nycklar är att autentisera klienten och servern. En kopia av sessionsnyckeln som skickas till servern krypteras med hjälp av serverns långtidsnyckel och som skickas till klienten krypteras med klientens långtidsnyckel. Teoretiskt, för att utföra funktionerna hos en betrodd mellanhand, räcker det för ett nyckeldistributionscenter att skicka sessionsnycklar direkt till säkerhetsabonnenter. Det är dock extremt svårt att genomföra ett sådant system i praktiken. Därför används i praktiken ett annat lösenordshanteringsschema, vilket gör Kerberos-protokollet mycket mer effektivt.

Sessionsbiljetter

Som svar på en begäran från en klient som har för avsikt att ansluta till servern skickar KDC-tjänsten båda kopiorna av sessionsnyckeln till klienten. Meddelandet som är avsett för klienten krypteras med en långtidsnyckel som delas mellan klienten och KDC, och sessionsnyckeln för servern, tillsammans med information om klienten, är inbäddad i ett datablock som kallas en sessionsbiljett. Hela sessionsbiljetten krypteras sedan med en långtidsnyckel som bara KDC-tjänsten och denna server känner till. Därefter ligger allt ansvar för att behandla ärendet, som bär den krypterade sessionsnyckeln, på klienten, som måste leverera den till servern. Efter att ha tagit emot KDC-svaret extraherar klienten biljetten och dess kopia av sessionsnyckeln från den, som den placerar i säker lagring (den finns inte på disken, utan i RAM ). När den behöver kontakta en server skickar klienten ett meddelande till den som består av en biljett, fortfarande krypterad med serverns långtidsnyckel, och en egen autentiseringsenhet, krypterad med sessionsnyckeln. Denna autentisering, i kombination med autentiseringsenheten, utgör den autentiseringsinformation med vilken servern bestämmer klientens "identitet". Servern, som har mottagit klientens "identitetskort", först och främst med hjälp av sin hemliga nyckel, dekrypterar sessionsbiljetten och extraherar sessionsnyckeln från den, som den sedan använder för att dekryptera klientautentiseringsanordningen. Om allt går bra dras slutsatsen att klientidentiteten har utfärdats av en betrodd mellanhand, det vill säga av KDC-tjänsten. Klienten kan kräva att servern utför ömsesidig autentisering. I det här fallet krypterar servern, med sin kopia av sessionsnyckeln, tidsstämpeln från klientens autentisering och skickar den till klienten som sin egen autentiseringsenhet. En fördel med att använda sessionsreferenser är att servern inte behöver lagra sessionsnycklar för att kommunicera med klienter. De lagras i klientens "credentials cache", som vidarebefordrar biljetten till servern varje gång den vill kontakta den. Servern å sin sida, efter att ha tagit emot biljetten från klienten, dekrypterar den och extraherar sessionsnyckeln. När nyckeln inte längre behövs kan servern helt enkelt radera den från sitt minne. Denna metod har ytterligare en fördel: klienten behöver inte kontakta KDC före varje session med en specifik server. Sessionsuppgifter kan återanvändas. I händelse av stöld ställs biljettens utgångsdatum in, vilket KDC anger i själva datastrukturen. Denna tid bestäms av den sfärspecifika Kerberos-policyn. Vanligtvis överstiger inte biljetternas giltighetstid åtta timmar, det vill säga standardlängden för en session i nätverket. När en användare loggar ut, återställs autentiseringscachen och alla sessionsuppgifter, tillsammans med sessionsnycklar, förstörs.

Protokollutveckling

Tidiga versioner

MIT utvecklade Kerberos för att säkra nätverkstjänster som tillhandahålls av Athena-projektet. Protokollet fick sitt namn efter den grekiska mytologiska karaktären Kerberos (eller Cerberus ), känd i grekisk mytologi som den monstruösa trehövdade vakthunden Hades. Det finns flera versioner av protokollet. Tidiga versioner av Kerberos (1 till 3) skapades internt av MIT och användes för teständamål. Dessa implementeringar innehöll betydande begränsningar och var endast användbara för att utforska nya idéer och identifiera problem som kan uppstå under utvecklingen.

Steve Miller och Clifford Neuman , huvuddesignerna av Kerberos version 4 (som använde DES-krypteringsalgoritmen med 56-bitars nycklar), publicerade den här versionen 1989, även om de fortfarande främst planerade den vid den tiden, i Athena-projektet.

Kerberos 4

Kerberos 4 publicerades första gången den 24 januari 1989 . Det var den första versionen som distribuerades utanför MIT, förberedd för flera leverantörer att inkludera den i sina operativsystem. Dessutom använde andra stora distribuerade systemprojekt (till exempel Andrew File System ) idéerna från Kerberos 4 för sina autentiseringssystem.

Grunden till det som skulle bli Kerberos 4 beskrevs i Athena whitepaper [1] , och den slutliga versionen solidifierades i källkoden för referensimplementeringen publicerad av MIT.

På grund av amerikanska myndigheters restriktioner för export av krypterad programvara kunde Kerberos 4 dock inte distribueras utanför USA. Eftersom Kerberos 4 använde DES- algoritmen för kryptering kunde organisationer utanför USA inte lagligt använda programvaran. Som svar skapade MITs utvecklingsteam en speciell version av Kerberos 4, som exkluderade all kod relaterad till kryptering från den. Dessa åtgärder gjorde det möjligt att kringgå exportrestriktionen.

Senare lade Errol Young vid Bond University of Australia till sin egen implementering av DES till denna utgåva. Det kallades "E-Bones" (förkortning för "encrypted bones" [2] ) och var gratis att distribuera utanför USA.

2006 tillkännagavs stöd för Kerberos 4 [3] .

Kerberos 5

För att övervinna säkerhetsproblemen i den tidigare versionen utvecklade John Kohl och Clifford Neuman version 5 av protokollet, som publicerades 1993 i RFC 1510 . Med tiden, 2005, började IETF Kerberos arbetsgrupp ta itu med specifikationen. Dokument de har publicerat inkluderar:

I juni 2006 introducerades RFC 4556 som beskriver en tillägg för version 5 som heter PKINIT ( public key  c ryptography for initial authentication in Kerberos ) . Denna RFC beskrev hur man använder asymmetrisk kryptering under klientautentiseringsfasen .

Året därpå (2007) bildade MIT Kerberos-konsortiet för att främja ytterligare utveckling.

Användning och distribution

Distribution av Kerberos-implementeringen sker under upphovsrätt, liknande BSD-rättigheter.

För närvarande stöder många operativsystem detta protokoll, inklusive:

Hur det fungerar

Kerberos 4

Kerberos 4 är till stor del baserad på Needham-Schroeder- protokollet , men med två betydande förändringar.

Som ett resultat innehåller Kerberos 4-protokollet två logiska komponenter:

Vanligtvis levereras dessa komponenter som ett enda program som körs på ett nyckeldistributionscenter (KDC - innehåller en databas med inloggningar/lösenord för användare och tjänster som använder Kerberos).

Autentiseringsservern utför en funktion: den tar emot en begäran som innehåller namnet på den klient som begär autentisering och returnerar en krypterad biljett till den för att erhålla en biljett (TGT). Användaren kan sedan använda denna biljett för att begära efterföljande biljetter för andra tjänster. I de flesta Kerberos-implementeringar är TGT:s livslängd 8-10 timmar. Efter det måste klienten återigen begära det från autentiseringsservern.

Det första meddelandet som skickas till nyckeldistributionscentret är en begäran till autentiseringsservern, även känd som AS_REQ. Detta meddelande skickas i klartext och innehåller klientens identitet, klientens tidsstämpel och ticket-granting server (TGS) identifierare.

När nyckeldistributionscentralen tar emot ett AS_REQ-meddelande kontrollerar den att klienten från vilken begäran kom från existerar, och dess tidsstämpel ligger nära centrets lokala tid (vanligtvis ± 5 minuter). Denna kontroll görs inte för att skydda mot repriser (meddelandet skickas i klartext), utan för att kontrollera tidpunkten. Om minst en av kontrollerna misslyckas skickas ett felmeddelande till klienten och det autentiseras inte.

Om autentiseringsservern lyckas genererar autentiseringsservern en slumpmässig sessionsnyckel som kommer att delas mellan klienten och biljett- eller beviljandeservern (denna nyckel skyddar framtida biljettförfrågningar för andra tjänster). Nyckeldistributionscentret skapar två kopior av sessionsnyckeln: en för klienten och en för biljettbeviljande server.

Nyckeldistributionscentret svarar sedan klienten med ett autentiseringsservermeddelande (AS_REP) krypterat med klientens långtidsnyckel. Detta meddelande inkluderar TGT krypterad med TGS-nyckeln, en kopia av sessionsnyckeln för klienten, biljettens livslängd och TGS-ID:t (TGT innehåller: en kopia av sessionsnyckeln för TGS, klient-ID, biljettens livslängd, Key Distribution Center (KDC) tidsstämpel, IP-adressklient).

När användaren vill komma åt tjänsten kommer han att förbereda ett meddelande för TGS_REQ som innehåller 3 delar: tjänsteidentifieraren, kopian av den tidigare mottagna TGT och autentiseringsenheten (autentiseringsenheten består av en tidsstämpel krypterad med sessionsnyckeln som tagits emot från autentiseringsserver och tjänar till att skydda mot upprepningar).

Vid mottagande av en ärendebegäran från en klient genererar KDC en ny sessionsnyckel för klient/tjänst-interaktionen. Den skickar sedan ett svarsmeddelande (TGS_REP) krypterat med den sessionsnyckel som tagits emot från autentiseringsservern. Det här meddelandet innehåller den nya sessionsnyckeln, tjänstebiljetten krypterad med den långsiktiga servicenyckeln, service-ID och biljettens livslängd (innehåller en kopia av den nya sessionsnyckeln, klient-ID, biljettens livslängd, lokal tid för nyckeldistributionscenter, klientens IP-adress ).

Detaljerna för det sista steget, att skicka tjänstebiljetten till applikationsservern, är inte standardiserade av Kerberos 4, så dess implementering är helt applikationsberoende.

Kerberos 5

Kerberos 5 är en utveckling av den fjärde versionen, innehåller all tidigare funktionalitet och innehåller många tillägg. Men ur implementeringssynpunkt är Kerberos 5 ett helt nytt protokoll.

Huvudskälet till utseendet på den femte versionen var omöjligheten av expansion. Med tiden blev en brute-force-attack på DES som användes i Kerberos 4 relevant, men fälten som användes i meddelanden hade en fast storlek och det gick inte att använda en starkare krypteringsalgoritm.

För att lösa detta problem beslutades att skapa ett utbyggbart protokoll som kan användas på olika plattformar baserat på ASN.1-teknik. Detta möjliggjorde användningen av olika typer av kryptering i transaktioner. Tack vare detta implementerades kompatibilitet med den tidigare versionen. Dessutom har KDC möjligheten att välja det säkraste krypteringsprotokollet som stöds av de deltagande parterna.

Dessutom är det ursprungliga Kerberos 4-protokollet föremål för ordboksuppräkning. Denna sårbarhet är relaterad till det faktum att KDC utfärdar en krypterad TGT på begäran till vilken klient som helst. Vikten av detta problem understryks också av det faktum att användare vanligtvis väljer enkla lösenord.

För att göra denna attack svårare introducerade Kerberos 5 förautentisering. I detta skede kräver KDC att användaren verifierar sin identitet innan de kan utfärdas en biljett.

KDC-policyn är ansvarig för förautentisering, om det krävs kommer användaren att få ett KRB_ERROR-meddelande vid den första begäran till autentiseringsservern. Detta meddelande kommer att berätta för klienten att skicka en AS_REQ-förfrågan med sina referenser för att autentisera. Om KDC inte känner igen dem, kommer användaren att få ett annat KRB_ERROR-meddelande som indikerar ett fel, och ingen TGT kommer att utfärdas.

Formell beskrivning Kryptografiska notationer som används i autentiserings- och nyckelutbytesprotokoll
Identifierare av Alice ( Alice ), initiativtagaren till sessionen
Identifierare för Bob ( Bob ), den sida från vilken sessionen etableras
Identifierare för Trent ( Trent ), en pålitlig mellanpart
Alice, Bob och Trents publika nycklar
Hemliga nycklar till Alice, Bob och Trent
Kryptering av data med Alices nyckel, eller Alice och Trents gemensamma nyckel
Kryptera data med Bobs nyckel eller Bob och Trents gemensamma nyckel
Datakryptering med hemliga nycklar från Alice, Bob (digital signatur)
Sessionssekvensnummer (för att förhindra reprisattacker)
Slumpmässig sessionsnyckel som ska användas för symmetrisk datakryptering
Krypterar data med en tillfällig sessionsnyckel
Tidsstämplar har lagts till i meddelanden av Alice respektive Bob
Slumptal ( nonce ) som valdes av Alice respektive Bob

Protokollet använder endast symmetrisk kryptering och förutsätter att varje korrespondent (Alice och Bob) delar en hemlig nyckel med en betrodd tredje part (Trent).

Alice skickar sitt ID och Bob till den betrodda parten (Trent):

Trent genererar två meddelanden. Den första inkluderar tidsstämpeln , nyckelns livslängd , den nya sessionsnyckeln för Alice och Bob och Bobs ID . Detta meddelande är krypterat med Alice och Trents delade nyckel. Det andra meddelandet innehåller samma, förutom identifieraren - den har ersatts med Alices identifierare . Själva meddelandet är krypterat med Trent och Bobs delade nyckel:

Alice genererar ett meddelande från sitt eget ID och en tidsstämpel , krypterar sedan meddelandet med sessionsnyckeln och skickar det till Bob tillsammans med det andra meddelandet från Trent:

För sin egen autentisering krypterar Bob den modifierade tidsstämpeln med en delad sessionsnyckel och skickar den till Alice:

Ett viktigt antagande är att alla protokolldeltagares klockor är synkroniserade. Men i praktiken används synkronisering med en noggrannhet på flera minuter, med överföringshistoriken lagrad (för att upptäcka upprepning) under en tid.

Detaljerad beskrivning

Så här fungerar Kerberos 5 för närvarande:

Användarnamn:

  1. Användaren anger ett användarnamn och lösenord på klientdatorn.
  2. Klientmaskinen utför en envägsfunktion (vanligtvis en hash) på lösenordet, och resultatet blir klientens/användarens hemliga nyckel.

Klientautentisering:

  1. Klienten skickar en begäran (AS_REQ) till CA för att erhålla autentiseringsuppgifter och sedan tillhandahålla dem till TGS-servern (senare kommer den att använda dem för att erhålla autentiseringsuppgifter utan ytterligare förfrågningar om att använda användarens hemliga nyckel.) Denna begäran innehåller:
    • Klient-ID, dess tidsstämpel och server-ID.
  2. Om KDC-policyn kräver förautentisering får användaren ett KRB_ERROR-meddelande, som svar på vilket han skickar en andra begäran, men med autentiseringsdata.
  3. CA kontrollerar om det finns en sådan klient i databasen. Om så är fallet skickar CA tillbaka ett meddelande (AS_REP) inklusive:
    • Klientens sessionsnyckel eller TGS, TGS-identifieraren och biljettens livslängd , krypterad med klientens privata nyckel .
    • TGT (som inkluderar klient-ID och nätverksadress, KDC-tidsstämpel, biljettens giltighetstid och klientsessionsnyckel eller TGS) krypterad med den hemliga TGS-nyckeln.

Om inte, får klienten ett nytt meddelande som indikerar att ett fel har inträffat.

  1. Vid mottagande av meddelandet dekrypterar klienten sin del för att erhålla klientens sessionsnyckel eller TGS. Denna sessionsnyckel används för vidare utbyte med TGS-servern. (Viktigt: Klienten kan inte dekryptera TGT eftersom den är krypterad med den hemliga TGS-nyckeln) Vid det här laget har användaren tillräckligt med autentiseringsuppgifter för att logga in på TGS.

Kundauktorisering på TGS:

  1. För att begära en tjänst genererar klienten en begäran om TGS (TGS_REQ) som innehåller följande data:
    • TGT erhöll tidigare och service-ID.
    • En autentisering (som består av ett klient-ID och en tidsstämpel) krypterad på klient-/TGS-sessionsnyckeln.
  2. Vid mottagande av TGS_REQ extraherar TGS TGT från den och dekrypterar den med den hemliga TGS-nyckeln. Detta ger honom klientens sessionsnyckel, eller TGS. Med den dekrypterar han autentiseringsenheten. Den genererar sedan en klient/tjänstsessionsnyckel och skickar ett svar (TGS_REP) inklusive:
    • servicebiljett (som innehåller klient-ID, klientnätverksadress, KDC-tidsstämpel, biljettens utgångstid och klient/tjänstsessionsnyckel) krypterad med tjänstens hemliga nyckel.
    • Klient-/tjänstesessionsnyckeln, tjänstidentifieraren och biljettens livslängd krypterade på klient/TGS-sessionsnyckeln.

Servicebegäran från kund:

  1. Efter att ha tagit emot TGS_REP har klienten tillräckligt med information för att auktorisera tjänsten. Klienten ansluter till den och skickar ett meddelande som innehåller:
    • Den krypterade tjänstebiljetten mottogs tidigare.
    • En ny autentiseringsenhet krypterad med klient-/tjänstsessionsnyckeln och inklusive klient-ID och tidsstämpel.
  2. Tjänsten dekrypterar biljetten med sin privata nyckel och erhåller klient/tjänstsessionsnyckeln. Med den nya nyckeln dekrypterar den autentiseringsenheten och skickar följande meddelande till klienten för att bekräfta att den är redo att betjäna klienten och att servern verkligen är den den utger sig för att vara:
    • Tidsstämpeln specificerad av klienten + 1 , krypterad med klient-/tjänstsessionsnyckeln.
  3. Klienten dekrypterar bekräftelsen med klient/tjänstsessionsnyckeln och kontrollerar att tidsstämpeln verkligen har uppdaterats korrekt. Om så är fallet kan klienten lita på servern och kan börja skicka förfrågningar till servern.
  4. Servern förser klienten med den begärda tjänsten.

PKINIT

PKINIT-tillägget påverkade klientens förautentiseringsstadium, varefter det började ske enligt följande:

  1. Användaren identifieras i systemet och presenterar sin privata nyckel.
  2. Klientmaskinen utfärdar en begäran till CA (AS_REQ) som indikerar att asymmetrisk kryptering kommer att användas. Skillnaden med denna begäran är att den är signerad (med hjälp av klientens privata nyckel) och innehåller, förutom standardinformationen, användarens certifikat för publika nyckel.
  3. Vid mottagande av begäran verifierar KDC först giltigheten av användarens certifikat och sedan den digitala signaturen (med hjälp av användarens mottagna offentliga nyckel) . Därefter kontrollerar KDC den lokala tiden som skickas i begäran (för att skydda mot repriser) .
  4. Efter att ha verifierat klientens äkthet genererar KDC ett svar (AS_REP), där, till skillnad från standardversionen, sessionsnyckeln krypteras med användarens publika nyckel. Dessutom innehåller svaret KDC-certifikatet och är signerat med dess privata nyckel (liknande klientens begäran) .
  5. Vid mottagande av svaret verifierar användaren KDC:s signatur och dekrypterar sin sessionsnyckel (med sin privata) .

Ytterligare steg sker enligt standardbeskrivningen av Kerberos V5.

Nackdelar och begränsningar

  • Single point of failure: Kräver en central server hela tiden. När Kerberos-servern går ner kan nya användare inte logga in. Detta kan fixas med flera Kerberos-servrar och reservautentiseringsmekanismer.
  • Kerberos har strikta tidskrav, vilket innebär att deltagarnas klockor måste hållas synkroniserade inom specificerade gränser. Inloggningsuppgifterna har en livstid och om klientens klocka inte är synkroniserad med Kerberos-serverns klocka kommer autentiseringen att misslyckas. Standardkonfigurationen kräver att klockorna inte är mer än fem minuters mellanrum. I praktiken används Network Time Protocol-demoner vanligtvis för att synkronisera klockor på klienter.
  • Administrationsprotokollet är inte standardiserat och beror på den specifika serverimplementeringen. Lösenordsändring beskrivs i RFC 3244.
  • När det gäller symmetrisk kryptografi (Kerberos kan fungera med både symmetrisk och asymmetrisk (public key) kryptografi), eftersom alla autentiseringsmetoder hanteras centralt av nyckeldistributionscentret (KDC), kommer den här funktionen i autentiseringsinfrastrukturen att tillåta en angripare att imitera sig. en användare.
  • Varje nätverkstjänst som kräver byte av värdnamn måste uppdatera sin egen uppsättning Kerberos-nycklar. Detta komplicerar användningen av delad hosting och kluster.
  • Kerberos kräver att användarkonton, klienter och tjänstanvändare på servern litar på Kerberos-servern (alla måste vara i samma domän som Kerberos eller i domäner som har en förtroenderelation med varandra). Kerberos kan inte användas i fall där användare vill ansluta till tjänster från okända/opålitliga klienter, som på det vanliga internet.

Sårbarheter

DES-chifferet kan användas med Kerberos, men det är inte längre en internetstandard eftersom det är sårbart. Sårbarheter finns dock i många produkter som använder Kerberos som inte har uppdaterats för att ersätta DES med nyare chiffer som AES till exempel.

I november 2014 släppte Microsoft en patch (MS14-068) för att åtgärda en sårbarhet i Windows-implementeringen av KDC-servern. Sårbarheten, enligt uttalandet, gjorde det möjligt för användare att "höja" sina privilegier till domännivån.

Se även

  • Teknik för enkel inloggning
  • identitetshantering
  • SPNEGO
  • S/Key
  • SRP (Secure Remote Password Protocol)
  • GSS-API (Generic Security Services Application Program Interface)
  • Host Identity Protocol (HIP)

Anteckningar

  1. ↑ Teknisk plan Arkiverad 1 januari 2016 på Athena Project Wayback Machine .
  2. ↑ Historik om namnet E-Bones  (otillgänglig länk)
  3. ↑ Meddelande om Kerberos version 4 End of Life . Hämtad 11 november 2011. Arkiverad från originalet 3 november 2011.

Litteratur

  • Schneier B. Kapitel 3. Grundläggande protokoll. Kerberos Protocol // Tillämpad kryptografi. Protokoll, algoritmer, källkod i C-språk = Applied Cryptography. Protocols, Algoritms and Source Code in C. - M . : Triumf, 2002. - P. 81. - 816 sid. - 3000 exemplar.  - ISBN 5-89392-055-4 .
  • Schneier B. Kapitel 24. Exempel på praktiska implementeringar. KERBEROS-protokoll // Tillämpad kryptografi. Protokoll, algoritmer, källkod i C-språk = Applied Cryptography. Protocols, Algoritms and Source Code i C. - M . : Triumf, 2002. - S. 627-633. — 816 sid. - 3000 exemplar.  - ISBN 5-89392-055-4 .
  • Jason Garman . 1-3 // Kerberos: The Definitive Guide  (neopr.) . - 2003. - ISBN 0-596-00403-6 .
  • Schneier B. Kapitel 24.5 Kerberos Bruce Schneier // Tillämpad kryptografi. Protokoll, algoritmer, källkod i C-språk = Applied Cryptography. Protocols, Algoritms and Source Code in C. - M. : Triumph, 2002. - 816 sid. - 3000 exemplar.  - ISBN 5-89392-055-4 .

Länkar

 Autentisering och nyckelutbytesprotokoll
Med symmetriska algoritmer
Med symmetriska och
asymmetriska algoritmer
Protokoll och tjänster som används på Internet