Architektura systemu Kerberos w wersji MIT Athena

Główne składowe systemu

• Biblioteka do tworzenia aplikacji ( API Kerberos )
  Interfejs dla klienckiej i serwerowej części aplikacji, zawiera wywołania systemowe dla tworzenia lub analizowania zapytań autentyfikacji oraz dla tworzenia prywatnych i bezpiecznych komunikatów
• Biblioteka do szyfrowania
  Szyfrowanie opiera się na Data Encryption Standard ( DES ).
  Stosowane metody : DES Cypher Block Chaining oraz, DES propagating Cypher Block Chaining. Moduł jest niezależną składową systemu i w każdej chwili może zostać zamieniony.
• System zarządzania bazami danych
  W głównej bazie są trzymane dane niezbędne dla autentyfikacji poszczególnych elementów systemu : identyfikator, klucz prywatny, termin ważności oraz administracyjna informacja.
  Dane ogólne o elemencie systemu są przechowywane na masynie zdalnej ( Hesiod ), co zmniejsza nakład związany z propagacją oraz pozwala udostępniać dane nie mające krytycznego wpływu na działanie systemu w sposób szybki ( możliwy brak szyfrowania ). Serwery autentyfikacji i administracji korzystają z tego modułu do przeprowadzania operacji na bazie danych.
• Serwer administracji ( ang. Kerberos Database Managment KDBM )
  Interfejs do operacji zapisu i odczytu na bazie danych. Kliencka część może się znajdować na dowolnej maszynie, część serwerowa może znajdować się na maszynie Master
• Serwer autentyfikacji ( Kerberos )
  Przeprowadza tylko i wyłącznie operacje odczytu na bazie danych w celach autentyfikacji elementów systemu i generowania kluczy sesji. Może działać jak na maszynie Master tak i na Slave
• Oprogramowanie do propagowania bazy danych
  wspomaga przesyłanie kopii danych z Master do Slave
• Programy użytkowników
  Klienckie programy po stronie użytkownika - do zalogowania się, do zmiany hasła, dodawanie/usuwanie użytkownika etc ( kpasswd, kinit, kadmin ... )
• Aplikacje
  Aplikacje programistyczne które korzystają z usług Kerberos ( korzystają z API Kerberosa )

Autentyfikacja typu ( user-to-host )

W wersji Kerberos 4 ( początkowo projektowany protokół ) jest założenie, że usługi systemowe są udostępniane na serwerach bezpiecznych, komunikacja z tymi serwerami odbywa się ze stacji roboczych o wolnym dostępie oraz przez sieć o której bezpieczeństwie nie wolno nic zakładać. Spowodowane jest to koniecznością pamiętania klucza prywatnego danej usługi w pamięci serwera usługi.

c -> klient

s -> serwer

addr -> sieciowy adres klienta

life -> czas ważności biletu

Kerberos -> serwer autentyfikacji

KDBM -> serwer administracji

tgs, TGS ( and. Ticket Grating Service ) -> serwer wydający kluczy sesji dla poczczególnych usług, wymaga okazania TGT (ang. Ticket-Granting-Ticket ) wydawanego przez Kerberos

K_x -> klucz prywatny x

K_x,y -> klucz sesji dla x i y

{abc}K_x -> abc zakodowane kluczem x

T_x,y -> bilet x dla korzystania z y

A_x -> poświadczenie dla x

• Ekspediowalne ( ang. forwardable ) - tylko dla TGT, przekazuje do TGS, informację, że może wysłać TGT z innym adresem na podstawie adresu w otrzymanym TGT.
• Wznawialne ( ang. renewable ) - pomocne dla aplikacji które powinny wykonywać obliczenia w tle przez okres dłuższy niż typowy czas istnienia biletu. Dość niebezpieczne jest używanie przez długi czas tego samego klucza sesji. Użytkownik w celu wzowienia biletu przesyła go wraz z autentyfikatorem do TGS, który sprawdza czy bilet jest aktualnie ważny i może zostać wznowiony. W pozytywnym przypadku znawianie biletu pociąga za sobą automatyczną zmianę klucza sesji, reszta danych biletu pozostaje bez zmian .
• Zastępcze ( ang. proxy ) - stosowane w pierwszym rozwiązaniu problemu delegowania autentyfikacji ( patrz dalej )
  
• Wykorzystywane w przyszłości (ang. postdatable ) - wydawane przez TGS, ale można będzie z nich skorzystać dopiero w przyszłości ( zastosowania : aplikacje uruchamiane okresowo ) .

Problem delegowania autentyfikacji : Klient ma dostęp do usług serwera N2 i chce żeby serwer N1 miał taki sam dostęp do usług serwera N2 jak klient, nie patrząc na to w jakiej relacji są serwer N1 i serwer N2.

Rozwiązanie 1 : klient pobiera bilet do serwera N2 i podaje go serwerowi N1 - niewygodne powinien zawsze znać nazwę serwera N2, co w większości aplikacji jest wyznaczane dynamicznie. Bilety używane w tym przypadku mają ustawioną flagę proxy.

Rozwiązanie 2 : klient wysyła do serwera N1 swój TGT, który powinien być forwardable.

Różnica pomiędzy biletami proxy a forwardable polega na niemożliwości delegowania biletu proxy w przypadku gdy jest on TGT. Bilety proxy są rzadziej stosowane w praktyce.

1. Żądanie biletu dla TGS
2. Bilet dla TGS ( TGT )
3. Żądanie biletu dla serwera
4. Bilet dla serwera
5. Żądanie obsługi zamówienia dla serwera

Czynności administracyjne

W implementacji zakłada się, że zmieniana może być zawartość tylko i wyłącznie bazy na maszynie Master, ale autentyfikacja może się odbywać jak i na Master tak i na Slave.

1. Żądanie biletu dla KDBM
2. Pobranie biletu
3. Żądanie kpasswd lub kadmin
4. Ewentualna aktualizacja danych ( zależnie od autoryzacji )
5. Zpisanie log'u ( następuje zawsze )

1. Program kprop na maszynie Master wylicza sumę kontrolną bazy
2. Przesyła sumę kontolną zakodowaną kluczem Master'a, który jest współdzielony przez Master i Slave, do programu nasłuchowującego kpropd na maszynie Slave, po czym przesyła dane z bazy ( każdy rekord w bazie jest zakodowany kluczem Master'a )
3. kpropd po otrzymaniu danych oblicza sumę kontrolną i porównuje z otrzymaną. W przypadku zgodności wzbogaca lokalną bazę o otrzymane dane

Kerberos z praktycznego punktu widzenia

Użytkownik

• logowanie - część zwykłego login
• zmiana hasła - część zwykłego passwd
• po wylogowaniu się użytkownika - wszystkie bilety są automatycznie kasowane

• W przypadku trwania sesji dłużej niż czas istnienia TGT - użytkownik powinien wprowadzić hasło
  ( uruchamiany jest proces kinit wysłania żądania TGT do TGS )
• Użytkownik uruchamiając klist może zobaczyć listę biletów używanych w jego imieniu

Programista

• Skorzystać z Biblioteki tworzenia aplikacji ( API Kerberos). Pomocne są wywołania krb_mk_req, krb_mk_priv dla strony klienckiej, oraz krb_rd_req, krb_mk_priv dla strony serwera
• Skorzystać z biblioteki do szyfrowania w przypadku wysyłania zakodowanych wiadomości

Administrator

1. Inicializacja bazy danych
2. Rejestracja poszczegónych elementów systemu ( użytkowników, usług )
3. Wystartowanie serwerów administrowania i autentyfikacji
4. W przypadku istnienia maszyn Slave wystartowanie demonów propagowania danych
5. Teraz administrator manipuluje systemem korzystając z programu kadmin

1. Zarejestruj usługę w bazie przydzielając jej klucz prywatny ( losowo generowany )
2. Zainstaluj dany klucz razem z pewnymi administracyjnymi danymi na maszynie usługi ( uaktualniając plik /etc/srvtab, który autentyfikuje serwer w podobny sposób jak hasło identyfikuje użytkownika )

Interakcja z innymi systemami Kerberos

1. Żądanie biletu do usługi ze zdalnego królewstwa od lokalnego TGS
2. Zwrot TGT do TGS ze zdalnego królewstwa zaszyfrowanego kluczem dzielonym
3. Ządanie biletu do usługi ze zdalnego królewstwa od zdalnego TGS
4. Uprawnienie "obcego" klienta do usługi lokalnej
5. Wysłanie żądania do usługi zdalnej
6. Otrzymanie odpowiedzi na zapytanie

1. Przydział każdej parze systemów klucza - niewygodne ( O(N²) kluczy )
2. Tranzytywna autentyfikacja ( tylko w Kerberos 5 ) polega na zdefiniowaniu ścieżek w systemie "idąc" którymi dochodzimy do żądanego systemu ( O(N) kluczy ). Jedną ze znanych metod tworzenia ścieżek jest grupowanie w chierarchię

Autentyfikacja typu ( user-to-user )

User-to-user jest protokołem zaimplementowanym w Kerberos 5. Pozwala on na udostępnianie w niebezpiecznej sieci bezpiecznych aplikacji na potencjalnie podejrzałych maszynach. W user-to-host dla udostępnienia usługi na maszynie zakładano że jest ona bezpieczna, bo przechowuje się w jej pamięci trwałej przez dość długi okres klucz prywatny danej usługi. Takie ograniczenie jest zbyt silne dla rzeczywistych potrzeb użytkowników. Przepowadzone badania wykazały, że w praktyce o wiele więcej razy występuje konieczność komunikacji user-to-user, niż user-to-host. Naprzykład użytkownik chce udostępnić usługi nfs lub ftp. Protokół udostępnia możliwość wystartowania serwera na stacji roboczej o dostępie swobodnym bez konieczności przechowywania klucza serwera w pamięci stacji. Jako klucza serwera używa się klucza sesji klienta dla TGT ( K_c,tgt ), którego czas istnienia jest mały.

1. Serwer Kerberos jest bezstanowy
2. Nie wolno dodać często zmienającego się stanu do bazy danych Kerberos
3. Kerberos może przeprowadzić tylko jedną tranzakcję w czasie danego połączenia
4. Przeciążenie serwera Kerberos jest niedopuszczalne
5. Nie istnieje kluczy o nieskończonym czasie istnienia

ale dla spełnienia aksjomatów trzeba trochę pomyśleć.

Przykład : Jak dostarczyć do TGS dwa TGT wraz z ich poświadczeniami ( jak zdobyć autentyfiktor usługi, pobranie samego TGT usługi jest bezpieczne ) ?

Autorzy protokołu user-to-user zrobili relaksację ograniczeń na komunikowanie się z TGS. Mianowicie, pokazali redundancje autentyfikatora dla TGS. Najpierw tworzono prostą analagię pomiędzy elementami uwierzytelniającymi dla TGS a zwykłą usługą, teraz - analogia z serwerem uwierzytelniającym Kerberos. Użytkownik autentyfikuje sam siebie przez zastosowanie klucza prywatnego do pakietu z TGT.

Główny cel systemu Kerberos - nie autentyfikacja elementów systemu, a dostarczanie usług dla autentyfikacji jednych elementów systemu przez inne.

Problemy otwarte

1. Optymalny czas istnienia biletu ?
2. Problem zastępcy. W jaki sposób autentyfikowany użytkownik może pozwolić serwerowi zdalnemu korzystać z usług systemu w jego imieniu ?
   Przykład : użytkownik jest zalogowany na jednej stacji, loguje się na zdalnią i chce żeby podczas wykonywania programu na maszynie zdalniej miał możliwość korzystania z usług do których miał dostęp na początkowej stacji
3. Jak zmniejszyć ryzyko padnięcia ofiarą "niewłaściwego" korzystania ze stacji roboczej ( podmiana oprogramowania na stacji roboczej, np. : login przekierowuje hasło do cracker'a ) ?

1. Wybieramy kompromis pomiędzy bezpieczeństwem a efektywnością. Długi czas istnienia biletu - wzrost przezroczystości, krótki - większy stopień bezpieczeństwa
2. Problem jest częściowo rozwiązany w Kerberos 5 przez wprowadzenie rodzaju biletów forwardable ( z ustawioną flagą TKT_FLG_FORWARDABLE ). Odpowiedzialność za pozwolenie na akceptację przez serwer autentyfikacji takich biletów leży na administratorze .
3. Spełnienie założenia : KLUCZ UŻYTKOWNIKA NIGDY NIE OPUSZCZA SYSTEMU O KTÓRYM UZYTKOWNIK WIE, ŻE JEST BEZPIECZNY. W praktyce szerokie zastosowanie znajdują SmartCards

Wykorzystana literatura

1. Jennifer G. Steiner, Clifford Neuman, Jeffrey I. Schiller, 1988. "Kerberos : An Authentication Service for Open Neworks".
2. Don Davis, Ralph Swick, 1989. "Workstation Services and Kerberos Authentication at Project Athena" .
3. G. Coulouris, J. Dollimore, T. Kindberg, 1998. "Systemy rozproszone, podstawy i projektowanie."
4. Steven M. Bellovin, and Michael Merrit, 1991. "Limitations of the Kerberos Authentication System."
5. John T. Kohl, B. Clifford Neuman, Theodore Y. Ts'o, 1992. "The Evolution of the Kerberos Authentication Service".
6. Kerberos FAQ.
7. S.P. Miller, B.C. Newman, J.I. Schiller, J.H. Saltzer, 1988. "Kerberos Authentication and Authorization System" ( Athena technical Plan ).