Kerberos (protokol)

História a vývoj

MIT vyvinula Kerberos na ochranu sieťových služieb poskytovaných v rámci projektu Athena. Protokol bol pomenovaný podľa gréckej mytologickej postavy Kerberos (alebo Cerberus), ktorá je v gréckej mytológii známa ako obludný trojhlavý strážny pes Háda. Existuje niekoľko verzií protokolu; verzie 1 až 3 sa používajú len interne na MIT.

Steve Miller a Clifford Neuman, hlavní konštruktéri Kerberosu verzie 4 (ktorá používala šifrovací algoritmus DES s 56-bitovými kľúčmi), uverejnili túto verziu v roku 1989, hoci sa zamerali predovšetkým na projekt Athena.

Verzia 5, ktorú navrhli John Kohl a Clifford Neuman, sa objavila ako RFC 1510 v roku 1993 (v roku 2005 ju zastaralo RFC 4120) so zámerom prekonať obmedzenia a bezpečnostné problémy verzie 4. MIT poskytuje implementáciu Kerberosu verzie 5 voľne dostupnú pod softvérovou licenciou podobnou licencii BSD.

Verziu 5 systému Kerberos použilo v komerčnom softvéri niekoľko spoločností vrátane:

·         Systém Windows 2000 a novšie systémy spoločnosti Microsoft používajú ako predvolenú metódu overovania Kerberos.
Niektoré doplnky spoločnosti Microsoft k súboru protokolov Kerberos sú zdokumentované v dokumente RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols".
RFC 4757 dokumentuje používanie šifry RC4
spoločnosťou Microsoft.
Hoci spoločnosť Microsoft používa protokol Kerberos, nepoužíva softvér MIT[1].

·         Systém Mac OS X od spoločnosti Apple tiež používa Kerberos vo verzii klienta aj servera.

·         Red Hat Linux verzie 4 a novšie používa Kerberos vo verzii klienta aj servera.

V roku 2005 pracovná skupina IETF Kerberos predstavila nové aktualizované špecifikácie pre Kerberos verzie 5 [2]:

·         "Špecifikácie šifrovania a kontrolných súčtov" (RFC 3961),

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

·         Nové vydanie špecifikácie Kerberos verzie 5 "The Kerberos Network Authentication Service (V5)" (RFC 4120). Táto verzia ruší RFC 1510, objasňuje aspekty protokolu a zamýšľané použitie v podrobnejšom jasnom vysvetlení,

·         Nové vydanie špecifikácie GSS-API "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Verzia 2." (RFC 4121).

V roku 2007 MIT vytvorila konzorcium Kerberos na pokračovanie vývoja.

Protokol

Kerberos používa ako základ Needham-Schroederov protokol. Využíva dôveryhodnú autentizáciu tretej strany známu ako "centrum distribúcie kľúčov (KDC)", ktoré sa skladá z dvoch logicky oddelených častí: autentizačného servera (AS) a servera na udeľovanie vstupeniek (TGS). Kerberos funguje na základe "lístkov" (nazývaných Kerberos tickets), ktoré slúžia na preukázanie identity používateľov.

Databáza Kerberos: Každý subjekt v sieti - či už klient alebo server - zdieľa tajný kľúč, ktorý je známy len jemu a KDC. Znalosť tohto kľúča slúži na preukázanie identity každej entity. Pri komunikácii medzi dvoma entitami KDC generuje kľúč relácie, ktorý môžu použiť na zabezpečenie svojej komunikácie.

Pojem "server Kerberos" sa vo všeobecnosti vzťahuje na KDC. Na účely spoľahlivosti je možné mať záložné KDC. Tie sa označujú ako "podriadené servery Kerberos". Všetky podriadené servery synchronizujú svoje databázy z hlavného servera Kerberos.

Termín "Kerberizovaný aplikačný server" sa vo všeobecnosti vzťahuje na Kerberizované programy, s ktorými klienti komunikujú pomocou Kerberos ticketov na overovanie. Napríklad telnetový server Kerberos je príkladom Kerberizovaného aplikačného servera . Zatiaľ čo termín "Kerberizované aplikácie" sa používa na označenie klientskej strany Kerberizovaného aplikačného servera , napríklad Kerberos telnet klient je príkladom Kerberizovaných aplikácií

Bezpečnosť protokolu do značnej miery závisí od:

1. Účastníci udržiavajú voľne synchronizovaný čas.
2. Krátkodobé vyhlásenie o pravosti: lístky Kerberos.

Zjednodušený opis protokolu

Budú sa používať tieto skratky:

·         AS = autentifikačný server

·         TGS = server na udeľovanie vstupeniek

·         SS alebo Server = Service Server (používateľ servera, ktorý požaduje jeho službu, napríklad tlačový server, súborový server atď.)

·         TGT = Ticket Granting Ticket (lístok Kerberos pre TGS. Pripravuje ho AS a potom sa používa na komunikáciu s TGS).

Stručne povedané, klient sa autentifikuje voči pridruženému systému pomocou dlhodobého zdieľaného tajomstva a od pridruženého systému dostane lístok. Neskôr môže klient použiť tento lístok na získanie ďalších lístkov pre SS s použitím toho istého zdieľaného tajomstva. Tieto lístky sa môžu použiť na preukázanie autentifikácie voči SS.

Podrobnejšie informácie o protokole

Kroky prihlásenia používateľa na základe klienta:

1. Používateľ zadá používateľské meno a heslo na klientskom počítači.
2. Klient vykoná jednosmernú funkciu (väčšinou funkciu Hash) na zadanom hesle, ktoré sa stane tajným kľúčom klienta/používateľa.

Kroky overovania klienta:

1. Klient odošle pridruženému systému správu s jasným textom, v ktorej žiada o služby v mene používateľa.
   Ukážka správy: "Používateľ XYZ by chcel požiadať o služby".
   Poznámka: Tajný kľúč ani heslo sa pridruženému systému neposielajú.
2. Pridružený systém skontroluje, či sa klient nachádza v jeho databáze. Ak áno, pridružený systém pošle klientovi späť nasledujúce dve správy:
• Správa A: Kľúč relácie klienta/TGS zašifrovaný pomocou tajného kľúča klienta/užívateľa.
• Správa B: TGT (ktorá obsahuje ID klienta, sieťovú adresu klienta, obdobie platnosti lístka a kľúč relácie klienta/TGS) zašifrovaný pomocou tajného kľúča TGS.
3. Po prijatí správ A a B klient dešifruje správu A, aby získal kľúč relácie klienta/TGS. Tento kľúč relácie sa používa na ďalšiu komunikáciu s TGS. V tomto okamihu má klient dostatok informácií na overenie svojej totožnosti voči TGS.
   Poznámka: Klient nemôže dešifrovať správu B, pretože je zašifrovaná pomocou tajného kľúča TGS.

Kroky autorizácie služieb pre klientov:

1. Pri žiadosti o služby klient pošle TGS tieto dve správy:
• Správa C: Pozostáva z TGT zo správy B a ID požadovanej služby.
• Správa D: Autentifikátor (ktorý sa skladá z ID klienta a časovej pečiatky), zašifrovaný pomocou kľúča relácie klienta/TGS.
2. Po prijatí správ C a D získa TGS zo správy C správu B. Správu B dešifruje pomocou tajného kľúča TGS. Tým získa kľúč relácie klienta/TGS. Pomocou tohto kľúča TGS dešifruje správu D (Autentifikátor) a odošle klientovi nasledujúce dve správy:
• Správa E: lístok medzi klientom a serverom (ktorý obsahuje ID klienta, sieťovú adresu klienta, obdobie platnosti a kľúč relácie klienta a servera) zašifrovaný pomocou tajného kľúča SS.
• Správa F: Kľúč relácie klienta/servera zašifrovaný kľúčom relácie klienta/TGS.

Kroky žiadosti o služby klienta:

1. Po prijatí správ E a F od TGS má klient dostatok informácií na overenie svojej totožnosti voči SS. Klient sa pripojí k SS a odošle nasledujúce dve správy:
• Správa E: z predchádzajúceho kroku (lístok medzi klientom a serverom zašifrovaný pomocou tajného kľúča SS).
• Správa G: nový autentifikátor, ktorý obsahuje ID klienta, časovú pečiatku a je zašifrovaný pomocou kľúča relácie klienta a servera.
2. SS dešifruje lístok pomocou svojho vlastného tajného kľúča na získanie kľúča relácie klient/server. Pomocou kľúča relácie SS dešifruje autentifikátor a odošle klientovi nasledujúcu správu na potvrdenie svojej skutočnej identity a ochoty obslúžiť klienta:
• Správa H: časová pečiatka nájdená v autentifikátore klienta plus 1, zašifrovaná pomocou kľúča relácie klienta a servera.
3. Klient dešifruje potvrdenie pomocou kľúča relácie klienta a servera a skontroluje, či je časová značka správne aktualizovaná. Ak áno, potom klient môže dôverovať serveru a môže začať vydávať požiadavky na služby na server.
4. Server poskytuje klientovi požadované služby.

Nevýhody

• Jediný bod zlyhania: Vyžaduje nepretržitú dostupnosť centrálneho servera. Ak je server Kerberos nefunkčný, nikto sa nemôže prihlásiť. Tento problém sa dá vyriešiť použitím viacerých serverov Kerberos a mechanizmov núdzového overovania.
• Kerberos vyžaduje, aby boli hodiny všetkých zúčastnených hostiteľov synchronizované. Tikety majú časovú dostupnosť a ak hodiny hostiteľa nie sú synchronizované s hodinami servera Kerberos, overenie zlyhá. Predvolená konfigurácia vyžaduje, aby časy hodín neboli od seba vzdialené viac ako 10 minút. V praxi sa na synchronizáciu všetkých hostiteľov zvyčajne používa sieťový časový protokol (NTP).
• Protokol správy nie je štandardizovaný a líši sa medzi jednotlivými implementáciami serverov. Zmeny hesiel sú opísané v dokumente RFC 3244.
• Keďže tajné kľúče všetkých používateľov sú uložené na centrálnom serveri, kompromitácia tohto servera ohrozí tajné kľúče všetkých používateľov.
• Kompromitovaný klient ohrozí heslo používateľa.

Súvisiace stránky

• Správa identít
• Bezpečný protokol vzdialeného hesla (SRP)
• Aplikačné programové rozhranie Generic Security Services (GSS-API)