Kerberos (datasäkerhet)

Historia och utveckling

MIT utvecklade Kerberos för att skydda de nätverkstjänster som tillhandahölls av Project Athena. Protokollet fick sitt namn efter den grekiska mytologiska karaktären Kerberos (eller Cerberus), som i den grekiska mytologin är känd som Hades monstruösa trehövdade vakthund. Det finns flera versioner av protokollet; versionerna 1-3 används endast internt vid MIT.

Steve Miller och Clifford Neuman, de främsta konstruktörerna av Kerberos version 4 (som använde krypteringsalgoritmen DES med 56-bitars nycklar), publicerade den versionen 1989, även om de i första hand hade riktat den till Project Athena.

Version 5, som utformades av John Kohl och Clifford Neuman, publicerades som RFC 1510 1993 (föråldrad genom RFC 4120 2005), i syfte att övervinna begränsningarna och säkerhetsproblemen i version 4. MIT gör en implementering av Kerberos version 5 fritt tillgänglig under en programvarulicens som liknar den som används av BSD-licensen.

Flera företag använde Kerberos version 5 i kommersiell programvara, bland annat:

·         Microsofts Windows 2000 och senare använder Kerberos som standardmetod för autentisering.
Några av Microsofts tillägg till Kerberos-protokollsatsen dokumenteras i RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols" (Microsoft Windows 2000 Kerberos protokoll för ändring av lösenord och fastställande av lösenord).
RFC 4757 dokumenterar Microsofts användning av RC4-chiffern. Microsoft använder Kerberos-protokollet, men inte MIT-programvaran[1].

·         Apples Mac OS X använder också Kerberos i både klient- och serverversioner.

·         Red Hat Linux version 4 och senare använder Kerberos i både klient- och serverversioner.

År 2005 presenterade IETF:s Kerberos-arbetsgrupp en ny uppdaterad specifikation för Kerberos version 5 [2]:

·         "Encryption and Checksum Specifications" (RFC 3961),

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

·         En ny utgåva av Kerberos version 5-specifikationen "The Kerberos Network Authentication Service (V5)" (RFC 4120). Denna version föråldrar RFC 1510, klargör aspekter av protokollet och den avsedda användningen i en mer detaljerad och tydlig förklaring,

·         En ny utgåva av GSS-API-specifikationen "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2." (RFC 4121).

År 2007 bildade MIT Kerberos Consortium för att fortsätta utvecklingen.

Protokoll

Kerberos bygger på Needham-Schroeder-protokollet. Det använder sig av en betrodd tredje parts autentisering som kallas "Key Distribution Center (KDC)", som består av två logiskt separata delar: en autentiseringsserver (AS) och en server för utfärdande av biljetter (TGS). Kerberos fungerar på grundval av "biljetter" (så kallade Kerberos-biljetter) som används för att bevisa användarnas identitet.

Kerberos-databas: Varje enhet i nätverket - oavsett om det är en klient eller en server - delar en hemlig nyckel som endast är känd för den själv och för KDC. Kännedom om denna nyckel tjänar som bevis för varje enhetens identitet. För kommunikation mellan två enheter genererar KDC en sessionsnyckel som de kan använda för att säkra sin kommunikation.

Termen "Kerberos-server" avser i allmänhet KDC. Av tillförlitlighetsskäl är det möjligt att ha backup-KDC:er. Dessa kallas "Kerberos-slaveservrar". Alla slavar synkroniserar sina databaser från den huvudsakliga Kerberos-servern.

Termen "Kerberiserad applikationsserver" avser i allmänhet Kerberiserade program som klienter kommunicerar med med hjälp av Kerberosbiljetter för autentisering. Kerberos telnet-server är till exempel ett exempel på en Kerberiserad applikationsserver . Medan termen "Kerberized applications" används för att hänvisa till klientsidan av Kerberized application server , till exempel Kerberos telnet-klienten är ett exempel på en Kerberized applications.

Protokollets säkerhet beror i hög grad på:

1. Deltagarna har löst synkroniserad tid.
2. En kortvarig äkthetsförklaring: Kerberos-biljetter.

Förenklad beskrivning av protokollet

Följande förkortningar kommer att användas:

·         AS = autentiseringsserver

·         TGS = Server för utfärdande av biljetter

·         SS eller Server = Service Server (Serveranvändare som begär sin tjänst, t.ex. en utskriftsserver, en filserver osv...).

·         TGT = Ticket Granting Ticket (Kerberos-biljett för TGS. Förbereds av AS och används sedan för att tala med TGS).

I korthet autentiserar klienten AS med hjälp av en långsiktig delad hemlighet och får en biljett från AS. Senare kan klienten använda denna biljett för att få ytterligare biljetter för SS med hjälp av samma delade hemlighet. Dessa biljetter kan användas för att bevisa autentisering till SS.

Protokollet i mer detalj

Klientbaserade inloggningssteg för användare:

1. En användare anger användarnamn och lösenord på klientmaskinen.
2. Klienten utför en envägsfunktion (oftast en hashfunktion) på det inmatade lösenordet och detta blir klientens/användarens hemliga nyckel.

Steg för klientautentisering:

1. Klienten skickar ett meddelande i klartext till systemet för att begära tjänster för användarens räkning.
   Exempel på meddelande: "Användaren XYZ vill begära tjänster.
   Observera: Varken den hemliga nyckeln eller lösenordet skickas till det anslutna systemet.
2. Systemet kontrollerar om klienten finns i dess databas. Om så är fallet skickar systemet tillbaka följande två meddelanden till klienten:
• Meddelande A: Klient/TGS-sessionsnyckel krypterad med klientens/användarens hemliga nyckel.
• Meddelande B: TGT (som innehåller klient-ID, klientnätverksadress, biljettens giltighetstid och klient/TGS-sessionsnyckeln) krypterad med hjälp av TGS:s hemliga nyckel.
3. När klienten har mottagit meddelanden A och B dekrypterar den meddelande A för att erhålla klient/TGS-sessionsnyckeln. Denna sessionsnyckel används för vidare kommunikation med TGS. Vid denna tidpunkt har klienten tillräckligt med information för att autentisera sig själv gentemot TGS.
   Anmärkning: Klienten kan inte dekryptera meddelande B, eftersom det är krypterat med hjälp av TGS:s hemliga nyckel.

Klienttjänstens auktoriseringssteg:

1. När klienten begär tjänster skickar klienten följande två meddelanden till TGS:
• Meddelande C: Består av TGT från meddelande B och ID för den begärda tjänsten.
• Meddelande D: Autentiserare (som består av klient-ID och tidsstämpel), krypterad med hjälp av klient/TGS-sessionsnyckeln.
2. När TGS tar emot meddelanden C och D hämtar TGS meddelande B från meddelande C. TGS dekrypterar meddelande B med hjälp av TGS hemliga nyckel. Detta ger klienten/TGS-sessionsnyckeln. Med hjälp av denna nyckel dekrypterar TGS meddelande D (autentiserare) och skickar följande två meddelanden till klienten:
• Meddelande E: Klient-till-server-biljett (som innehåller klient-ID, klientnätverksadress, giltighetstid och klient/server-sessionsnyckel) krypterad med SS hemliga nyckel.
• Meddelande F: Klient/Server-sessionsnyckel krypterad med klient/TGS-sessionsnyckel.

Stegen för begäran om kundtjänst:

1. När klienten får meddelanden E och F från TGS har klienten tillräckligt med information för att autentisera sig mot SS. Klienten ansluter till SS och skickar följande två meddelanden:
• Meddelande E: från föregående steg (klient-till-server-biljetten, krypterad med SS hemliga nyckel).
• Meddelande G: en ny autentiserare, som innehåller klient-ID, tidsstämpel och krypteras med klient- och serversessionsnyckel.
2. SS dekrypterar biljetten med hjälp av sin egen hemliga nyckel för att få fram klient/server-sessionsnyckeln. Med hjälp av sessionsnyckeln dekrypterar SS autentiseraren och skickar följande meddelande till klienten för att bekräfta sin sanna identitet och sin vilja att betjäna klienten:
• Meddelande H: den tidsstämpel som finns i klientens autentiserare plus 1, krypterad med klient/server-sessionsnyckeln.
3. Klienten dekrypterar bekräftelsen med hjälp av sessionsnyckeln för klient/server och kontrollerar om tidsstämpeln är korrekt uppdaterad. Om så är fallet kan klienten lita på servern och börja skicka tjänsteförfrågningar till servern.
4. Servern tillhandahåller de begärda tjänsterna till klienten.

Nackdelar

• En enda felpunkt: Det kräver kontinuerlig tillgänglighet för en central server. När Kerberos-servern är nere kan ingen logga in. Detta kan lösas genom att använda flera Kerberos-servrar och mekanismer för nödautentisering.
• Kerberos kräver att klockorna på alla inblandade värdar är synkroniserade. Biljetterna har en tidsperiod för tillgänglighet och om värdklockan inte är synkroniserad med Kerberos-serverns klocka kommer autentiseringen att misslyckas. Standardkonfigurationen kräver att klocktiderna inte skiljer sig mer än 10 minuter från varandra. I praktiken används vanligtvis Network Time Protocol (NTP) för att hålla alla värdar synkroniserade.
• Administrationsprotokollet är inte standardiserat och skiljer sig åt mellan olika serverimplementationer. Lösenordsändringar beskrivs i RFC 3244.
• Eftersom de hemliga nycklarna för alla användare lagras på den centrala servern, kommer ett intrång i den servern att äventyra alla användares hemliga nycklar.
• En infekterad klient kommer att avslöja användarens lösenord.

Relaterade sidor

• Identitetshantering
• Protokoll för säkert fjärrlösenord (SRP)
• Programgränssnitt för generiska säkerhetstjänster (GSS-API)