Tomasz Okniński 2003r.
Kerberos
Spis treści
- Tytułem wstępu
- Podstawowe założenia
- Zasada działania
- System nazewnictwa
- Różnice między Kerberosem 4 i 5
- Zapobieganie złamaniu bezpieczeństwa
- Inne darmowe wersje Kerberosa
1. Tytułem wstępu...
Internet nie jest bezpiecznym miejscem. Otwarte kanały łączności umożliwiają podsłuchiwanie niezaszyfrowanych danych i haseł. W ten sposób osoby trzecie mogą uzyskać dostęp do tajnych informacji.
Próbą powstrzymania tego było stworzenie firewalla. Idea firewalla zakłada jednak, że "źli faceci" są na zewnątrz chronionej sieci i stamtąd próbują się włamać. Niestety jest to często błędne założenie, a ponadto firewall utrudnia pracę użytkownikom i może całkiem uniemożliwić korzystanie z niektórych aplikacji (Firewall jest w istocie łagodnym podejściem do zastosowania w praktyce twierdzenia, że najbezpieczniejszy komputer to taki, który nie jest podłączony do sieci i w dodatku jest w ogóle wyłączony).
System autentykacji Kerberos powstał na MIT (Massachusetts Institute od Technology) aby zapewnić użytkownikom otwartej sieci potrzebne im bezpieczeństwo przechowywanych i przesyłanych danych przez udzielanie do nich dostępu tylko uprawnionym jednostkom.
Kerberos nie zajmuje się jednak przechowywaniem danych, a jedynie przyznaje (bądź nie) dostęp do określonych usług sieciowych. Korzysta przy tym z bazy danych o użytkownikach i dostępnych usługach oraz szyfrowania komunikacji przesyłanej po otwartych łączach. Dzięki temu klienci mogą bezpiecznie korzystać z danych i usług udostępnianych w Internecie i mniejszych sieciach intranetowych.
Obecnie wersja 4 została uznana za przestarzałą i jej rozwój zakończył się na wersji "patchlevel 10". W tej chwili prace trwają jedynie nad wersją 5.
Kerberos 4 patchlevel 10 można uzyskać w sposób opisany tu: ftp://athena-dist.mit.edu/pub/kerberos/README.KRB4
Najnowszą wersją Kerberosa w wersji 5 jest 1.2.7 dostępny pod http://web.mit.edu/kerberos/www/
2. Podstawowe założenia
- Kerberos jest protokołem autentykacyjnym
- W ramach Kerberosa działają klienci i usługi oraz Centrum Dystrybucji Kluczy (KDC). Dostęp do usług jest zapewniany klientom po ich uwierzytelnieniu w KDC
- Korzysta z systemu szyfrowanych komunikatów (biletów) do przedstawiania się klientów serwerom w systemie
- Serwery używają specjalnych komunikatów zwanych autentykatorami do potwierdzania biletów
- Jest to standardowy protokół autentykacji w MS Windows 2000
- Zakłada się, że terminale są bezpieczne, a zagrożenie stanowi otwarte łącze
- Kerberos jest szybszy i oferuje większe możliwości niż NTLM używany w NT 4.0 i Windowsach 9X
- Szyfrowanie w Kerberosie 4 odbywa się przy użyciu DES'a, a w wersji 5 za pomocą wymiennych modułów. Całe szyfrowanie odbywa się przy użyciu tajnych (znanych tylko zainteresowanym stronom) kluczy symetrycznych
Ważne informacje
- W systemie w ramach Centrum Dystrybucji Kluczy działają:
- Authentication Server (AS), który przyznaje TGT klientom usiłującym skorzystać z usług w ramach Kerberosa
- Ticket-granting Service (TGS) czyli serwis przyznający bilety na podstawie TGT
- TGT to specjalny bilet, który otrzymuje klient z potwierdzoną tożsamością w systemie Kerberos. Umożliwia on klientowi ubieganie się o bilety do serwisów
- Bilet umożliwia klientowi uzyskanie dostępu do danego serwisu
- Bilet zawiera:
- nazwę serwera
- nazwę klienta
- IP klienta
- stempel czasowy
- czas życia biletu
- klucz sesji
- Bilet może być wykorzystywany wielokrotnie aż do wyczerpania się jego czasu życia
- Bilet jest szyfrowany kluczem symetrycznym, specyficznym dla danego serwera, na którym jest usługa
- Autentykator służy do potwierdzenia autentyczności biletu
- Autentykator może być użyty tylko raz. Gry klient chce skorzystać z usługi, musi być utworzony nowy autentykator. Na szczęście klient może go sam wystawić i nie obciąża się dodatkowo serwera usługi.
- Autentykator zawiera:
- nazwę klienta
- IP stacji roboczej
- aktualny czas na stacji roboczej
- Autentykator jest szyfrowany kluczem sesji
3. Zasada działania
3.1 Uzyskanie TGT - zalogowanie do Kerberosa
- Klient podaje nazwę użytkownika
- Zostaje wysłane żądanie do Serwera Autentykacji (AS)
- AS tworzy TGT - bilet do komunikacji klient-TGS z nazwą serwera TGS, nazwą klienta, IP klienta, stemplem czasowym, czasem życia dla biletu i kluczem sesji wygenerowanym losowo
- AS szyfruje TGT przy pomocy klucza wyliczonego z hasła użytkownika, które jest znane AS i następnie odsyła TGT do klienta (istnieje funkcja, która dla danego hasła w postaci ciągu bitów, tworzy z niego klucz do szyfrowania symetrycznego)
- Klient podaje hasło użytkownika
- Na podstawie hasła jest generowany klucz do odszyfrowania TGT
- TGT i jego klucz sesji zostają zachowane do późniejszego użycia, a hasło użytkownika i wygenerowany z niego klucz zostają usunięte z pamięci dla bezpieczeństwa
3.2 Uzyskanie biletu do usługi
- Klient buduje autentykator ze swoją nazwą, IP i obecnym czasem i szyfruje za pomocą klucza sesji z TGT
- Klient wysyła żądanie wydania biletu do danego serwera, TGT i autentykator do serwera TGS
- Serwer odczytuje TGT, następnie odkodowuje autentykator przy użyciu klucza sesji z TGT i sprawdza poprawność otrzymanych danych (TGT<-> autentykator, IP, obecny czas)
- Jeśli wszystko się zgadza, TGS generuje nowy losowy klucz sesji, który będzie używany w komunikacji klient-serwer usługi. Następnie tworzy bilet dla klienta zapisując tam nazwę serwera usługi, nazwę klienta, IP klienta, stempel czasowy, czas życia biletu (wybierany jest mniejszy spośród standardowego czasu dla biletu i pozostałego czasu życia dla TGT) i nowy klucz sesji
- Bilet jest szyfrowany kluczem prywatnym serwera usługi (znanym tylko temu serwerowi i TGS) i odsyłany do klienta razem z nowym kluczem sesji zaszyfrowanym kluczem sesji dla TGT
3.3 Uzyskanie dostępu do usługi
- Klient buduje autentykator i szyfruje go za pomocą klucza sesji otrzymanego razem z biletem
- Klient wysyła bilet i autentykator do serwera usługi
- Serwer odkodowuje bilet swoim kluczem prywatnym, następnie odkodowuje autentykator przy użyciu klucza sesji z biletu i sprawdza poprawność otrzymanych danych (bilet<-> autentykator, IP, obecny czas)
- Jeśli wszystko się zgadza, oznacza to, że klient i serwer dysponują kluczem sesji znanym tylko sobie nawzajem. Klient otrzymuje dostęp do serwisu i może wysyłać dane szyfrując je symetrycznym kluczem sesji.
W Kerberosie bardzo ważna jest synchronizacja czasu pomiędzy klientami i serwerami działającymi w systemie. Różnice powyżej kilku minut mogą uniemożliwić dostęp do usług.
Dzieje się tak z tego powodu, że jeśli rozbieżność czasu z biletu i czasu na serwerze jest zbyt duża, serwer traktuje pakiet jako próbę ponownego wysłania żądania (tzw. replay)
Aby zabezpieczyć się przed włamaniami, serwery utrzymują bazę danych odebranych już żądań dostępu do usług, wraz z ich stemplami czasowymi. Dzięki temu "skradzione bilety" nie mogą być jeszcze raz wysłane, ani zostać zachowane do wysłania w późniejszym terminie.
3.4 Autentykacja serwera
Po otrzymaniu dostępu do serwisu, klient może od serwera domagać się jego uwierzytelnienia.
Wtedy serwer zwiększa stempel czasowy z autentykatora o 1, szyfruje to przy pomocy klucza sesji i odsyła klientowi.
To potwierdza, że serwer jest w posiadaniu klucza sesji, gdyż odszyfrował bilet (w którym był właśnie klucz sesji), który był zakodowany przez KDC hasłem zrozumiałym tylko dla niego.
To oznacza również, że serwer odczytał autentykator, który był zakodowany kluczem sesji. Jest to nieco wtórne sprawdzenie znajomości klucza sesji, gdyż jest nim przecież kodowana odpowiedź. Mimo to, jest ono również używane.
Sposób otrzymania dostępu do usługi ABCD
4. System nazewnictwa
Częścią autenykacji w Kerberosie jest potwierdzenie, że użytkownik jest tym za kogo się podaje. Dlatego musi mieć swoją nazwę.
Nazwa w Kerberosie 4 wygląda tak:
nazwa.wcielenie@królestwo
- nazwa (name)
- nazwa użytkownika
- wcielenie (instance)
- służy do rozróżniania wystąpień nazwy - może być to np. nazwa hosta albo rodzaj uprzywilejowania (np. root)
- królestwo (realm)
- środowisko (domena) obsługiwane przez pojedynczą bazę danych autentykacyjnych
Ponadto każdy element nazwy może się składać z 39 znaków i nie może zawierać kropek (.)
W Kerberosie 5 nazwy mają inną budowę:
nazwa@królestwo
przy czym nazwa składa się z ciągu komponentów oddzielonych ukośnikami (/) i może być dowolnie długa i zawierać kropki (.)
Najczęściej utrzymywana jest wtedy struktura drzewa w celu zhierarchizowania komunikacji między królestwami
Komunikacja między Królestwami
Użytkownik może otrzymać dostęp do zasobu spoza swojego królestwa. Musi w tym celu zgłosić się do swojego KDC po TGT do serwera KDC z innego królestwa. Dalej już zgłasza się po bilety w odpowiednie miejsce.
Komunikacja między królestwami może się odbywać, jeśli dane 2 królestwa posiadają wspólny, ustalony wcześniej, klucz do szyfrowania komunikatów.
Niestety w Kerberosie 4, jeśli klient chce przejść przez wiele królestw to musi za każdym razem otrzymywać TGT dla kolejnych KDC i może wymagać to aż O(n^2) komunikatów.
W Kerberosie 5 ten koszt został zredukowany do O(log(n)) dzięki wykorzystaniu możliwego połączenia bezpośrednio z docelowym królestwem bądź którymś z sąsiednich.
Połączenia między Królestwami w wersji 4
Połączenia między Królestwami w wersji 5
5. Różnice między Kerberosem 4 i 5
Wady Kerberosa 4
- Wykorzystanie DES'a - w wielu krajach import i eksport technologii kryptograficznych jest zabroniony (np. w USA), co utrudnia rozprowadzanie produktu
- Do adresowania używa się protokołu IP - w niektórych architekturach sieci (np. opartych o IPX) uniemożliwia to używanie Kerberosa
- czas życia jest zapisywany na 8 bitach (w 5-minutowych jednostkach), co pozwala na maksymalny czas jedynie 21,25 h - uniemożliwia to np. długotrwałe działanie symulacji, które korzystają ze zdalnych usług
- Brak przekazywania autentykacji, aby serwer mógł wykonywać akcje z uprawnieniami użytkownika i dokończyć wykonywanie jakiejś operacji za niego (np. przy zlecaniu drukowania, serwer drukujący powinien mieć dostęp do pliku użytkownika, żeby móc go wydrukować)
- Ograniczenia w systemie nazewnictwa - niemożność wykorzystania kropek w nazwie użytkownika może być przeszkodą w systemach, w których nazwy użytkowników zawierają kropki (jak to się dzieje np. na zodiacu w przypadku aliasów typu: t.okninski)
Zmiany w Kerberosie 5
- Szyfrowanie odbywa się przy pomocy wymiennych modułów, niezależnych od implementacji Kerberosa. Dzięki temu sam kod Kerberosa jest łatwo rozprowadzalny, a szyfrowanie można dołączyć na miejscu bez problemów
- Adresy sieciowe mają znaczniki typu, więc mogą być wykorzystywane różne protokoły, niekoniecznie IP
- Wszelka komunikacja jest ustandaryzowana i wykorzystywana jest w tym celu notacja ASN.1
- Hasło jest permutowane przy pomocy nazwy królestwa, dlatego to samo hasło użyte w różnych królestwach będzie inaczej zaszyfrowane
- Bilety mają zmodyfikowaną strukturę - tylko część informacji musi być szyfrowana, a pozostałe mogą być wykorzystywane do spersonalizowania i usprawnienia obsługi żądań. Dodatkowo pojawiły się nowe opcje umożliwiające rozszerzenie możliwości protokołu:
- Odnawialne bilety - bilet ma 2 czasy życia: aktualny i maksymalny. Przed upłynięciem czasu maksymalnego bilet może zostać odnowiony i przedłuża się jego czas życia aby np. dokończyć długotrwałą operację
- Z przyszłą datą wystawienia - można zażądać biletu, który będzie oznaczony tymczasowo jako nieprawidłowy do wykorzystania dopiero w przyszłości - użyteczne w przypadku gdy dostęp do serwisu będzie potrzebny dopiero za jakiś czas (np. przy wykonywaniu skryptów)
- Przekazywanie biletów - umożliwia przekazanie uprawnień klienta serwerowi, aby ten działał w jego imieniu. Dzięki temu serwer może otrzymywać bilety do inych serwerów tak jakby był danym użytkownikiem i wykonywać za niego operacje. Bilety mogą być przekazywane na 2 sposoby - z możliwością uzyskiwania TGT od innych KDC i bez niej
- Klucze podsesji - klient i serwer mogą uzgodnić nowy klucz do wykorzystania w sesji - może być użyteczne, jeśli zachodzi potrzeba wysłania wiadomości w trybie rozgłoszeniowym i inni odbiorcy mają odszyfrować daną wiadomość
6. Zapobieganie złamaniu bezpieczeństwa
- Osobny bilet jest wymagany dla każdej usługi, więc w razie wejścia w posiadanie jednego biletu, nie można go wykorzystać do uzyskania dostępu do innej usługi
- Przechowywanie informacji na serwerach o otrzymanych biletach zapobiega replayom żądań. Tak samo przechwycone bilety nie mogą zostać wysłane w późniejszym terminie ze względu na porównywanie stempli czasowych. Dlatego tak ważna jest poprawna synchronizacja czasu pomiędzy składowymi systemu - standardowo tolerancja jest do 5 minut
- Żadne klucze nie są przesyłane przez sieć w postaci niezakodowanej. Niepotrzebne klucze i hasła są usuwane z pamięci i z dysku od razu po wykorzystaniu.
- Klucze wykorzystywane w pojedynczej komunikacji są znane jedynie klientowi, serwerowi i KDC. Jedynie w przypadku renegocjacji klucza podsesji w Kerberosie 5 można dołączyć do komunikacji większą ilość rozmówców.
- Bilety i TGT posiadają swój określony czas życia aby w przypadku udanego przechwycenia takiego biletu ograniczyć możliwości jego wykorzystania. Możliwość przedłużania czasu życia jest w pewnym stopniu złamaniem tej zasady na korzyść wygody użytkownika, więc w konfiguracji Kerberosa można uniemożliwić takie przedłużanie.
- Hasła wykorzystywane w Kerberosie są z natury w postaci liczbowej, jednak badania wykazały, że użytkownicy mają trudności za zapamiętywaniem długich ciągów cyfr. Dlatego wykorzystuje się funkcje, które z haseł wprowadzanych jako ciągi liter wyliczają ciąg bitów. Są to funkcje jednokierunkowe, dlatego niemożliwe jest poznanie hasła użytkownika znając jedynie jego zapis cyfrowy. Nigdzie w systemie nie są trzymane hasła w postaci literowej, a ponieważ w Kerberosie 5 hasło użytkownika jest szyfrowane dodatkowo przez nazwę królestwa, jeśli osoba trzecia wejdzie w posiadanie cyfrowego hasła w jednym królestwie, nie ma możliwości podszywania się pod użytkownika w innym królestwie
7. Inne darmowe wersje Kerberosa
Tomasz Okniński 2003r.