V sobotu 2. listopadu proběhla mohutná oslava naší plnoletosti !!
Multimediaexpo.cz je již 18 let na českém internetu !!
V tiskové zprávě k 18. narozeninám brzy najdete nové a zásadní informace.

Kerberos (protokol)

Z Multimediaexpo.cz

Ikona protokolu

Kerberos je síťový autentizační protokol umožňující komukoli komunikujícímu v nezabezpečené síti prokázat bezpečně svoji identitu někomu dalšímu. Kerberos zabraňuje odposlechnutí nebo zopakování takovéto komunikace a zaručuje integritu dat. Byl vytvořen primárně pro model klient-server a poskytuje vzájemnou autentizaci – klient i server si ověří identitu své protistrany.

Kerberos je postavený na symetrické kryptografii, a proto potřebuje důvěryhodnou třetí stranu. Volitelně může využívat asymetrického šifrování v určitých částech autentizačního procesu. Standardně používá port 88.

Historie a vývoj

Kerberos byl vyvinut na Massachusettském technologickém institutu (MIT) k ochraně síťových služeb v rámci projektu Athena. Jméno vzniklo z řeckého Kerberos (Cerberus), což byl trojhlavý pes střežící vstup do podsvětí. Kerberos existuje v několika verzích z čehož verze 1-3 sloužily pouze vnitřním potřebám MIT. Steve Miller a Clifford Neumann, prvotní autoři 4. verze protokolu Kerberos, tuto vydali roku 1987, avšak stále byla primárně určena potřebám projektu Athena. Verze 5 byla oficiálně vydána roku 1993 – viz RFC 1510 (roku 2005 nahrazena RFC 4120) – s úmyslem překonat omezení a bezpečnostní rizika verze 4. MIT vydává Kerberos pod licencí velmi podobnou BSD. Roku 2007 bylo založeno Kerberos Consortium na podporu budoucího vývoje protokolu. Mezi zakládající sponzory patří např. Sun Microsystems, Apple Inc., Google, Microsoft, Centrify Corporation a akademické instituce jako např. KTH-Royal Institute of Technology, Stanfordova univerzita nebo MIT. Kerberos byl úřady v USA klasifikován jako pomocná vojenská technologie a zároveň byl zakázán jeho export, protože používal šifru DES. Tento zákaz obešla švédská The Royal Institute of Technology tím, že vydala vlastní verzi 4 založenou na omezené verzi eBones od MIT zbavenou šifrovacích funkcí a volání na ně. Tím byl Kerberos uvolněn i mimo USA do doby, než se změnila jejich vývozní politika. Windows od verze 2000 dále využívají Kerberos jako standardní zabezpečovací metodu. Některé doplňky od Microsoftu do kerberovské skupiny protokolů jsou zdokumentovány v RFC 3244. RFC 4757 dokumentuje použití šifry RC4 společnosti Microsoft. Přestože Microsoft používá protokol Kerberos, nevyužívá k tomu software od MIT. Mnoho na UNIXu založených operačních systémů (včetně FreeBSD, Mac OS X od Apple, Red Hat Enterprise Linux, Solaris od Sun, AIX od IBM, OpenVMS od Hewlett-Packard a ostatních) také zahrnuje nástroje pro autentizaci služeb a uživatelů pomoci protokolu Kerberos. Od roku 2005 se aktualizací specifikací protokolu Kerberos zabývá IETF.

Protokol

Fungování protokolu Kerberos

Teorie

Kerberos je založen na Needham-Schroeder Symmetric Key Protocol. Používá důvěryhodné třetí strany nazývané též Key Distribution Center (KDC) sestávající ze dvou logicky oddělených částí: Autentizačního serveru (AS) a Ticket-Granting Serveru (TGS). Kerberos pracuje na principu tiketů sloužících k ověření identity uživatelů.

KDC si udržuje databázi tajných klíčů; každá entita v sítí, ať už klient nebo server, vlastní svůj tajný klíč známý pouze jí a KDC. Znalost tohoto klíče slouží k prokázání identity dané entity. Pro komunikaci mezi entitami KDC vygeneruje „session key“, kterým obě protistrany zabezpečí vzájemnou komunikaci. Bezpečnost tohoto protokolu významně závisí na vzájemné synchronizaci času protistran a krátké životnosti tiketů.

Popis

Nejdříve si definujeme několik zkratek 
AS 
Autentizační server
SS 
Servisní středisko
TGS 
Ticket-granting server – řídicí server
TGT 
Ticket granting ticket – tiket opravňující uživatele ke komunikaci s řídícím serverem

Vlastní autentizační proces si popíšeme nejdříve zjednodušeně: Klient se autentizuje vůči AS a obdrží tiket. Poté kontaktuje TGS a pomocí tiketu prokáže svou identitu a požádá o přístup ke službě. Pokud na něj má nárok, pošle TGS klientu další tiket, který je použit při komunikaci se SS je jím potvrzen nárok na službu.

Detailnější popis vypadá následovně: Klient se jednorázově autentizuje AS pomocí navzájem známého tajemství (např. heslo) a dostane TGT. Později, když chce klient kontaktovat nějaké SS, použije se (i opakovaně) tohoto TGT k ověření u TGS a tím k získání tiketu pro komunikaci se SS bez toho, aby bylo znovu využíváno původního známého tajemství.

Následuje popis jednotlivých fází:

Login uživatele

  1. Uživatel vloží své jméno a heslo na klientském počítači.
  2. Klient provede jednostrannou funkci (obvykle Hash) na vloženém hesle a to se stane tajným klíčem pro klienta/uživatele (klíč 1).

Autentizace klienta

  1. Klient odešle nešifrovaně zprávu na AS obsahující uživatelovo ID a jeho žádost o přístup ke službě. (všimneme si, že jak heslo tak ani uživatelův tajný klíč nejsou odeslány) AS vygeneruje tajný klíč Hashováním hesla uživatele, které vyhledá v databázi.
  2. AS zkontroluje zda se uživatel nachází v jeho databázi. Pokud ano, odešle klientu nazpět 2 zprávy:
    • zpráva A: Klient/TGS klíč (klíč 2) zašifrovaný klíčem klient/uživatel (klíč 1).
    • zpráva B: TGT obsahující ID klienta, jeho síťovou adresu, životnost tohoto tiketu a klient/TGS klíč (klíč 2), to vše zašifrované tajným klíčem TGS (klíč 3).
  3. Jakmile klient obdrží zprávy A a B, pokusí se dešifrovat zprávu A klíčem vygenerovaným z hesla uživatele (klíč 1). Pokud uživatel vložil nesprávné heslo tj. rozdílné než to, co má v databázi AS, klíč 1 nebude odpovídat a tudíž s ním nepůjde dešifrovat zpráva A. Se správným heslem a tudíž i správným klíčem rozšifruje klient zprávu A čímž získá klient/TGS klíč (klíč2). Tento je využíván pro další komunikaci s TGS. (všimneme si, že klient nedokáže dešifrovat zprávu B jelikož je šifrována s použitím tajného klíče TGS (klíč 3)) V tuto chvíli má klient dostatek informací k autentizaci vůči TGS.

Autorizace přístupu ke službě

  1. Žádost o přístup ke službě se skládá ze dvou zpráv, jež klient odešle na TGS:
    • zpráva C: Ta obsahuje zprávu B a ID služby ke které klient žádá přístup.
    • zpráva D: Autentikátor (složený z ID klienta a časové značky) šifrovaný klient/TGS klíčem (klíč 2)
  2. Po obdržení zpráv C a D rozkóduje TGS zprávu C z níž získá zprávu B kterou dále dešifruje svým tajným klíčem (klíč 3). Tím získá klient/TGS klíč (klíč 2). Pomocí tohoto klíče dále dešifruje zprávu D (autentikátor) a odešle klientu následující dvě zprávy:
    • zpráva E: Klient/server tiket ,obsahující ID klienta, jeho síťovou adresu, dobu platnosti a klient/server klíč (klíč 4), to vše zašifrované tajným klíčem služby (klíč 5).
    • zpráva F: Klient/server klíč (klíč 4) šifrovaný klient/TGS klíčem (klíč 2).

Vyřízení žádosti o přístup ke službě

  1. Jakmile klient obdrží zprávy E a F od TGS, má dostatek informací k autentizaci vůči SS. Klient se k němu připojí a odešle mu tyto dvě zprávy:
    • zpráva E: z předchozího kroku (klient/server tiket zašifrovaný tajným klíčem služby (klíč 5).
    • zpráva G: Nový autentikátor, obsahující ID klienta a časovou značku, zašifrovaný klient/server klíčem (klíč 4).
  2. SS dešifruje zprávu E pomocí svého tajného klíče (klíč 5) a získá tak klient/server klíč (klíč 4). Tímto pak dešifruje zprávu G z níž zjistí autentikátor a poté odešle klientu zpět následující zprávu, aby potvrdil svou identitu a ochotu posloužit klientu:
    • zpráva H: časová značka z klientova autentikátoru navýšená o 1, zašifrovaná klient/server klíčem (klíč 4).
  3. Klient dešifruje zprávu H klient/server klíčem (klíč 4) a zkontroluje, zda je časová značka správně navýšena. Pokud ano, tak může klient serveru důvěřovat a také může začít posílat žádosti o služby na server.
  4. Server poskytuje klientu služby o které žádá.

Rizika

  • Největší riziko spočívá v nutnosti nepřetržitého běhu centrálního serveru. Pokud tento server neběží, nikdo se nemůže přihlásit. Toto riziko lze zmírnit použitím více Kerberos serverů a záložních autentizačních mechanismů.
  • Kerberos má přísné požadavky na synchronizaci času klientů a serverů. Tikety mají danou životnost a pokud není čas klienta synchronizován s časem serveru, autentizace selže. Standardní nastavení podle MIT požaduje, aby se tyto časy nerozcházely o více jak 5 minut. V praxi se používá NTP (Network Time Protocol) démonů k synchronizaci hodin.
  • Administrační protokol není standardizován a liší se podle implementace. Změna hesla je popsána v RFC 3244.
  • Jelikož je veškerá autentizace řízena centrálně přes KDC (Key Distribution Center), narušením této autentizační infrastruktury dostane útočník možnost vydávat se za jakéhokoliv uživatele.

Související články

Externí odkazy


Citováno z „http://ww.multimediaexpo.cz/mmecz/index.php/Kerberos_(protokol)“