Kerberos (protokol)

Historie a vývoj

MIT vyvinul systém Kerberos k ochraně síťových služeb poskytovaných v rámci projektu Athena. Protokol byl pojmenován po řecké mytologické postavě Kerberos (nebo Cerberus), která je v řecké mytologii známá jako obludný tříhlavý Hádův hlídací pes. Existuje několik verzí protokolu; verze 1-3 se používají pouze interně v MIT.

Steve Miller a Clifford Neuman, hlavní tvůrci Kerberosu verze 4 (která používala šifrovací algoritmus DES s 56bitovými klíči), publikovali tuto verzi v roce 1989, ačkoli ji primárně určili pro projekt Athena.

Verze 5, navržená Johnem Kohlem a Cliffordem Neumanem, se objevila jako RFC 1510 v roce 1993 (zastarala v RFC 4120 v roce 2005) s cílem překonat omezení a bezpečnostní problémy verze 4. MIT poskytuje implementaci Kerberosu verze 5 volně k dispozici pod softwarovou licencí podobnou licenci BSD.

Několik společností použilo Kerberos verze 5 v komerčním softwaru, včetně:

·         Systém Windows 2000 a novější od společnosti Microsoft používají jako výchozí metodu ověřování Kerberos.
Některé doplňky společnosti Microsoft k sadě protokolů Kerberos jsou zdokumentovány v dokumentu RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols".
RFC 4757 dokumentuje použití šifry RC4
společností Microsoft. Společnost Microsoft
sice používá protokol Kerberos, ale nepoužívá software MIT[1].

·         Systém Mac OS X od společnosti Apple také používá Kerberos ve své klientské i serverové verzi.

·         Red Hat Linux verze 4 a novější používá Kerberos ve verzi klienta i serveru.

V roce 2005 představila pracovní skupina IETF Kerberos nové aktualizované specifikace pro Kerberos verze 5 [2]:

·         "Specifikace šifrování a kontrolních součtů" (RFC 3961),

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

·         Nové vydání specifikace Kerberos verze 5 "The Kerberos Network Authentication Service (V5)" (RFC 4120). Tato verze ruší RFC 1510, objasňuje aspekty protokolu a zamýšleného použití v podrobnějším jasném vysvětlení,

·         Nové vydání specifikace GSS-API "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Verze 2." (RFC 4121).

V roce 2007 založil MIT konsorcium Kerberos pro pokračování vývoje.

Protokol

Kerberos používá jako základ protokol Needham-Schroeder. Využívá důvěryhodnou třetí stranu pro ověřování známou jako "distribuční centrum klíčů (KDC)", které se skládá ze dvou logicky oddělených částí: autentizačního serveru (AS) a serveru pro udělování vstupenek (TGS). Kerberos funguje na základě "ticketů" (tzv. Kerberos ticketů), které slouží k prokázání identity uživatelů.

databáze Kerberos: Každý subjekt v síti - klient nebo server - sdílí tajný klíč, který zná pouze on sám a KDC. Znalost tohoto klíče slouží k prokázání identity každé entity. Pro komunikaci mezi dvěma entitami generuje KDC klíč relace, který mohou tyto entity použít k zabezpečení své komunikace.

Termínem "server Kerberos" se obecně označuje KDC. Pro účely spolehlivosti je možné mít záložní KDC. Ty se označují jako "podřízené servery Kerberos". Všechny podřízené servery synchronizují své databáze z hlavního serveru Kerberos.

Termín "aplikační server s Kerberem" obecně označuje programy s Kerberem, s nimiž klienti komunikují pomocí tiketů Kerberos pro ověřování. Příkladem kerberizovaného aplikačního serveru je například telnetový server Kerberos . Zatímco termín "kerberizované aplikace" se používá pro označení klientské strany kerberizovaného aplikačního serveru , například klient telnetu Kerberos je příkladem kerberizovaných aplikací.

Bezpečnost protokolu závisí do značné míry na:

1. Účastníci udržují volně synchronizovaný čas.
2. Krátkodobé prohlášení o pravosti: lístky Kerberos.

Zjednodušený popis protokolu

Používají se následující zkratky:

·         AS = ověřovací server

·         TGS = server pro udělování vstupenek

·         SS nebo Server = Service Server (Uživatel serveru, který požaduje jeho službu, například tiskový server, souborový server atd...)

·         TGT = Ticket Granting Ticket (lístek Kerberos pro TGS. Připravený přidruženým systémem a poté použitý pro komunikaci s TGS).

Stručně řečeno, klient se ověří u přidruženého systému pomocí dlouhodobě sdíleného tajemství a obdrží od přidruženého systému tiket. Později může klient tento lístek použít k získání dalších lístků pro SS s použitím stejného sdíleného tajemství. Tyto tikety lze použít k prokázání ověření SS.

Podrobnější informace o protokolu

Kroky přihlášení uživatele na základě klienta:

1. Uživatel zadá uživatelské jméno a heslo na klientském počítači.
2. Klient provede nad zadaným heslem jednosměrnou funkci (většinou funkci Hash), která se stane tajným klíčem klienta/uživatele.

Kroky ověřování klienta:

1. Klient odešle přidruženému systému zprávu s otevřeným textem, ve které jménem uživatele žádá o služby.
   Ukázka zprávy: "User XYZ would like to request services" (Uživatel XYZ žádá o služby).
   Poznámka: Tajný klíč ani heslo se přidruženému systému nezasílají.
2. Přidružený systém zkontroluje, zda je klient v jeho databázi. Pokud ano, vyšle přidružený systém klientovi zpět následující dvě zprávy:
• Zpráva A: Klíč relace klienta/TGS zašifrovaný pomocí tajného klíče klienta/uživatele.
• Zpráva B: TGT (obsahuje ID klienta, adresu sítě klienta, dobu platnosti tiketu a klíč relace klienta/TGS) zašifrovaný pomocí tajného klíče TGS.
3. Jakmile klient obdrží zprávy A a B, dešifruje zprávu A a získá klíč relace klienta/TGS. Tento klíč relace se používá pro další komunikaci s TGS. V tomto okamžiku má klient dostatek informací k ověření své totožnosti vůči TGS.
   Poznámka: Klient nemůže dešifrovat zprávu B, protože je zašifrována pomocí tajného klíče TGS.

Kroky autorizace klientských služeb:

1. Při požadavku na služby odešle klient do TGS následující dvě zprávy:
• Zpráva C: Skládá se z TGT ze zprávy B a ID požadované služby.
• Zpráva D: Autentikátor (který se skládá z ID klienta a časového razítka), zašifrovaný pomocí klíče relace klienta/TGS.
2. Po přijetí zpráv C a D získá TGS ze zprávy C zprávu B. Zprávu B dešifruje pomocí tajného klíče TGS. Tím získá klíč relace klienta a TGS. Pomocí tohoto klíče TGS dešifruje zprávu D (Authenticator) a odešle klientovi následující dvě zprávy:
• Zpráva E: Tiket mezi klientem a serverem (který obsahuje ID klienta, síťovou adresu klienta, dobu platnosti a klíč relace klienta a serveru) zašifrovaný pomocí tajného klíče SS.
• Zpráva F: Klíč relace klient/server zašifrovaný klíčem relace klient/TGS.

Kroky při vyřizování žádosti o služby pro klienty:

1. Po obdržení zpráv E a F od TGS má klient dostatek informací, aby se mohl autentizovat vůči SS. Klient se připojí k SS a odešle následující dvě zprávy:
• Zpráva E: z předchozího kroku (lístek mezi klientem a serverem zašifrovaný pomocí tajného klíče SS).
• Zpráva G: nový autentizátor, který obsahuje ID klienta, časové razítko a je zašifrován pomocí klíče relace klienta a serveru.
2. SS dešifruje tiket pomocí svého vlastního tajného klíče a získá klíč relace klient/server. Pomocí klíče relace SS dešifruje autentizátor a odešle klientovi následující zprávu, aby potvrdil svou skutečnou identitu a ochotu klienta obsloužit:
• Zpráva H: časové razítko nalezené v klientově autentizačním zařízení plus 1, zašifrované pomocí klíče relace klienta a serveru.
3. Klient dešifruje potvrzení pomocí klíče relace klienta a serveru a zkontroluje, zda je časové razítko správně aktualizováno. Pokud ano, klient může serveru důvěřovat a může začít vydávat požadavky na služby serveru.
4. Server poskytuje klientovi požadované služby.

Nevýhody

• Jediný bod selhání: Vyžaduje nepřetržitou dostupnost centrálního serveru. Pokud je server Kerberos mimo provoz, nikdo se nemůže přihlásit. To lze vyřešit použitím více serverů Kerberos a nouzových mechanismů ověřování.
• Kerberos vyžaduje synchronizaci hodin všech zúčastněných hostitelů. Tikety mají dobu dostupnosti, a pokud hodiny hostitele nejsou synchronizovány s hodinami serveru Kerberos, ověření selže. Výchozí konfigurace vyžaduje, aby časy hodin nebyly od sebe vzdáleny více než 10 minut. V praxi se k synchronizaci všech hostitelů obvykle používá protokol NTP (Network Time Protocol).
• Protokol správy není standardizován a liší se mezi jednotlivými implementacemi serverů. Změny hesel jsou popsány v RFC 3244.
• Vzhledem k tomu, že tajné klíče všech uživatelů jsou uloženy na centrálním serveru, kompromitace tohoto serveru povede ke kompromitaci tajných klíčů všech uživatelů.
• Kompromitovaný klient ohrozí heslo uživatele.

Související stránky

• Správa identit
• Protokol SRP (Secure remote password protocol)
• Aplikační programové rozhraní Generic Security Services (GSS-API)