Kerberos (informatyka)

Historia i rozwój

MIT opracował Kerberos w celu ochrony usług sieciowych dostarczanych w ramach Projektu Athena. Nazwa protokołu pochodzi od greckiej mitologicznej postaci Kerberosa (lub Cerbera), znanego w mitologii greckiej jako potworny trójgłowy pies stróżujący Hadesa. Istnieje kilka wersji tego protokołu; wersje 1-3 są używane tylko wewnętrznie w MIT.

Steve Miller i Clifford Neuman, główni projektanci Kerberosa w wersji 4 (wykorzystującej algorytm szyfrowania DES z 56-bitowymi kluczami), opublikowali tę wersję w 1989 roku, choć przeznaczyli ją głównie dla Projektu Athena.

Wersja 5, zaprojektowana przez Johna Kohla i Clifforda Neumana, pojawiła się jako RFC 1510 w 1993 roku (zdezaktualizowana przez RFC 4120 w 2005 roku), z zamiarem przezwyciężenia ograniczeń i problemów bezpieczeństwa wersji 4. MIT udostępnia implementację Kerberosa w wersji 5 za darmo, na licencji oprogramowania podobnej do tej używanej przez licencję BSD.

Kilka firm używało Kerberos Version 5 w komercyjnym oprogramowaniu, w tym:

·         Systemy Windows 2000 i późniejsze firmy Microsoft używają protokołu Kerberos jako domyślnej metody uwierzytelniania.
Niektóre dodatki firmy Microsoft do zestawu protokołów Kerberos są udokumentowane w dokumencie RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols". RFC
4757 dokumentuje użycie przez Microsoft szyfru RC4.
Chociaż Microsoft używa protokołu Kerberos, nie korzysta z oprogramowania MIT.[1]

·         System Mac OS X firmy Apple również wykorzystuje Kerberos zarówno w wersji klienckiej, jak i serwerowej.

·         Red Hat Linux w wersji 4 i nowszych używa Kerberos zarówno w wersji klienta jak i serwera.

W 2005 roku grupa robocza IETF Kerberos wprowadziła nową, zaktualizowaną specyfikację dla Kerberos Version 5 [2]. aktualizacje obejmują:

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

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

·         Nowe wydanie specyfikacji Kerberos Version 5 "The Kerberos Network Authentication Service (V5)" (RFC 4120). Ta wersja unieważnia RFC 1510, wyjaśnia aspekty protokołu i przeznaczenie w bardziej szczegółowym i przejrzystym wyjaśnieniu,

·         Nowe wydanie specyfikacji GSS-API "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2." (RFC 4121).

W 2007 roku MIT utworzył Kerberos Consortium w celu kontynuacji rozwoju.

Protokół

Kerberos wykorzystuje jako podstawę protokół Needham-Schroeder. Wykorzystuje on uwierzytelnianie przez zaufaną trzecią stronę, znaną jako "centrum dystrybucji kluczy (KDC)", które składa się z dwóch logicznie oddzielnych części: serwera uwierzytelniającego (AS) i serwera przyznającego bilety (TGS). Kerberos działa w oparciu o "bilety" (zwane Kerberos tickets), które służą do potwierdzania tożsamości użytkowników.

Baza danych Kerberos: Centrum dystrybucji kluczy (KDC) utrzymuje bazę danych tajnych kluczy; każdy podmiot w sieci - czy to klient, czy serwer - współdzieli tajny klucz znany tylko sobie i KDC. Znajomość tego klucza służy do potwierdzenia tożsamości każdego podmiotu. W przypadku komunikacji pomiędzy dwoma podmiotami, KDC generuje klucz sesji, który mogą one wykorzystać do zabezpieczenia swojej komunikacji.

Termin "serwer Kerberos" odnosi się ogólnie do KDC. Dla celów niezawodności, możliwe jest posiadanie zapasowych KDC. Są one nazywane "serwerami Kerberos slave". Wszystkie serwery slave synchronizują swoje bazy danych z głównego serwera Kerberos.

Termin "serwer aplikacji Kerberized" odnosi się ogólnie do programów Kerberized, z którymi klienci komunikują się przy użyciu biletów Kerberos do uwierzytelniania. Na przykład, serwer telnet Kerberos jest przykładem serwera aplikacji Kerberized . Podczas gdy termin "Kerberized applications" jest używany w odniesieniu do strony klienta Kerberized application server, na przykład, Kerberos telnet client jest przykładem Kerberized applications.

Bezpieczeństwo protokołu zależy w dużej mierze od:

1. Uczestnicy utrzymujący luźno zsynchronizowany czas.
2. A Krótkotrwała deklaracja autentyczności: bilety Kerberos.

Uproszczony opis protokołu

Stosowane będą następujące skróty:

·         AS = serwer uwierzytelniający

·         TGS = Ticket Granting Server

·         SS lub Server = Service Server (użytkownik serwera żądający jego usługi, jak np. serwer wydruku, serwer plików, itp.)

·         TGT = Ticket Granting Ticket (bilet Kerberos dla TGS. Przygotowany przez AS, używany do rozmowy z TGS).

W skrócie, klient uwierzytelnia się w AS używając długoterminowego współdzielonego sekretu i otrzymuje bilet od AS. Później klient może użyć tego biletu do uzyskania dodatkowych biletów dla SS używając tego samego współdzielonego sekretu. Te bilety mogą być użyte do udowodnienia uwierzytelnienia do SS.

Szczegółowe informacje na temat protokołu

Kroki logowania oparte na kliencie użytkownika:

1. Użytkownik wprowadza nazwę użytkownika i hasło na komputerze klienckim.
2. Klient wykonuje funkcję jednokierunkową (najczęściej funkcję Hash) na wprowadzonym haśle, a to staje się tajnym kluczem klienta/użytkownika.

Kroki uwierzytelniania klienta:

1. Klient wysyła wiadomość typu cleartext do systemu zewnętrznego z żądaniem świadczenia usług w imieniu użytkownika.
   Przykładowa wiadomość: "Użytkownik XYZ chciałby zażądać usług".
   Uwaga: Ani klucz tajny, ani hasło nie są przesyłane do systemu zewnętrznego.
2. AS sprawdza, czy klient znajduje się w jego bazie danych. Jeśli tak, AS odsyła do klienta dwie poniższe wiadomości:
• Komunikat A: Klucz sesji klienta/TGS zaszyfrowany przy użyciu tajnego klucza klienta/użytkownika.
• Komunikat B: TGT (który zawiera identyfikator klienta, adres sieciowy klienta, okres ważności biletu i klucz sesji klienta/TGS) zaszyfrowany przy użyciu tajnego klucza TGS.
3. Po otrzymaniu wiadomości A i B, klient odszyfrowuje wiadomość A w celu uzyskania klucza sesji klienta/TGS. Ten klucz sesji jest używany do dalszej komunikacji z TGS. W tym momencie klient posiada wystarczającą ilość informacji, aby uwierzytelnić się w systemie TGS.
   Uwaga: Klient nie może odszyfrować komunikatu B, ponieważ jest on zaszyfrowany przy użyciu tajnego klucza systemu TGS.

Etapy autoryzacji obsługi klienta:

1. Przy zamawianiu usług klient wysyła do systemu TGS następujące dwa komunikaty:
• Komunikat C: Sklada się z TGT z komunikatu B i identyfikatora żądanej uslugi.
• Komunikat D: Uwierzytelniacz (składający się z ID klienta i znacznika czasu), zaszyfrowany przy użyciu Klucza Sesji Klient/TGS.
2. Po otrzymaniu wiadomości C i D, system TGS pobiera wiadomość B z wiadomości C. Odszyfrowuje wiadomość B używając tajnego klucza TGS. W ten sposób uzyskuje klucz sesji Klient/TGS. Używając tego klucza, system TGS odszyfrowuje wiadomość D (Authenticator) i wysyła do klienta następujące dwie wiadomości:
• Komunikat E: Bilet klient-serwer (który zawiera identyfikator klienta, adres sieciowy klienta, okres ważności i klucz sesji klient-serwer) zaszyfrowany przy użyciu tajnego klucza SS.
• Komunikat F: Klucz sesji Klient/Serwer zaszyfrowany kluczem sesji Klient/TGS.

Etapy obsługi klienta:

1. Po otrzymaniu wiadomości E i F od TGS, klient posiada wystarczającą ilość informacji, aby uwierzytelnić się w SS. Klient łączy się z SS i wysyła następujące dwie wiadomości:
• Wiadomość E: z poprzedniego kroku (bilet klient-serwer, zaszyfrowany przy użyciu tajnego klucza SS).
• Wiadomość G: nowy Authenticator, który zawiera ID klienta, timestamp i jest zaszyfrowany przy użyciu Client/Server Session Key.
2. SS odszyfrowuje bilet używając własnego tajnego klucza, aby uzyskać klucz sesji Client/Server Session Key. Używając klucza sesji, SS deszyfruje Authenticator i wysyła następującą wiadomość do klienta, aby potwierdzić swoją prawdziwą tożsamość i chęć obsługi klienta:
• Message H: znacznik czasu znaleziony w Authenticator klienta plus 1, zaszyfrowany przy użyciu Client/Server Session Key.
3. Klient odszyfrowuje potwierdzenie za pomocą klucza sesji klienta/serwera i sprawdza, czy znacznik czasu jest poprawnie zaktualizowany. Jeśli tak, to klient może zaufać serwerowi i może rozpocząć wysyłanie żądań serwisowych do serwera.
4. Serwer dostarcza żądane usługi do klienta.

Wady

• Pojedynczy punkt awarii: Wymaga ciągłej dostępności centralnego serwera. Gdy serwer Kerberos przestanie działać, nikt nie będzie mógł się zalogować. Można to rozwiązać poprzez użycie wielu serwerów Kerberos i awaryjnych mechanizmów uwierzytelniania.
• Kerberos wymaga, aby zegary wszystkich zaangażowanych hostów były zsynchronizowane. Bilety mają określony czas dostępności i jeśli zegar hosta nie jest zsynchronizowany z zegarem serwera Kerberos, uwierzytelnienie nie powiedzie się. Domyślna konfiguracja wymaga, aby czasy zegarów nie były oddalone od siebie o więcej niż 10 minut. W praktyce Network Time Protocol (NTP) jest zwykle używany do synchronizacji wszystkich hostów.
• Protokół administracyjny nie jest standaryzowany i różni się pomiędzy implementacjami serwerów. Zmiana hasła jest opisana w RFC 3244.
• Ponieważ tajne klucze wszystkich użytkowników są przechowywane na centralnym serwerze, kompromitacja tego serwera spowoduje kompromitację tajnych kluczy wszystkich użytkowników.
• Skompromitowany klient będzie kompromitował hasło użytkownika.

Powiązane strony

• Zarządzanie tożsamością
• Protokół bezpiecznego hasła zdalnego (SRP)
• Interfejs programowy generycznych usług bezpieczeństwa (GSS-API)