Korzenie
● Oparty o protokół uwierzytelniania z zaufaną stroną
trzecią zaprezentowany w 1978 przez Roger`a
Needham i Michael`a Schroeder
● Projekt Athena na Massachusetts Institute for
Technology (MIT)
– początek w 1983
– 1989 – pierwsze publiczne wydanie Kerberos v4
– od połowy lat 90`tych funkcjonuje Kerberos v5
3.
Funkcje
● uwierzytelnianie (ang. authentication)
– proces potwierdzania tożsamości
● autoryzacja (ang. authorization)
– proces ustalania praw dostępu do usług
● ewidencjonowanie (ang. auditing)
– dostarcza informacji o pomyślnym lub
nieprawidłowym przebiegu uwierzytelniania i
autoryzacji
4.
Cechy
● bezpieczeństwo
– oparty o ulegające przedawnieniu bilety (ang.
tickets)
● pośrednictwo strony trzeciej (arbitra)
● single-sign-on
– uwierzytelnianie dla nieograniczonej liczby usług
bez potrzeby ponownego wprowadzania hasła
● obustronne uwierzytelnianie
– uwierzytelnianie zarówno klienta jak i usługi
5.
Pojęcia związane zKerberosem
● aktorzy (ang. principals)
– strony biorące udział w protokole: użytkownicy i usługi
● realms – domeny, przestrzenie administracyjne
– obszar podległy danemu serwerowi Kerberos
● klucz, salt i hasło
– klucze są współdzielone między przynajmniej dwoma
stronami
– salt to wartość dołączana do hasła przed wykonaniem
funkcji skrótu podczas tworzenia klucza
● zwiększa to bezpieczeństwo w przypadku złamania klucza
w obrębie jednej z wielu wykorzystywanych domen
6.
Aktor
● jest opisywany przez trzy komponenty:
– nazwę użytkownika/usługi
– opcjonalnych instancji
– domeny (realm)
● wzorce nazw aktorów:
– username[/instance]@REALM
– service/fully-qualified-domain-name@REALM
przykład:
– host/unixsvr.it.wedgie.org@IT.WEDGIE.ORG
7.
Key Distribution Center- KDC
● Centralny serwer KDC składa się z trzech
logicznych komponentów:
– bazy wszystkich uczestników i odpowiadających
im kluczy (może to być także np. Active Directory)
– serwera uwierzytelniającego – Authentication
Server (AS)
– serwera biletów – Ticket Granting Server (TGS)
8.
Bilety
● Bilety zawierają:
– nazwę użytkownika
– nazwę usługi
– datę od kiedy bilet jest ważny i na jak długo
– listę adresów IP z których bilet może być
wykorzystywany
– wspólny, sekretny klucz sesji komunikacji
użytkownik-usługa
9.
Działanie Kerberos V5cz.1
● Klient wysyła komunikat do serwera uwierzytelniającego
z prośbą o TGT.
● Serwer uwierzytelniający przygotowuje dwie kopie
klucza sesji.
● Tworzony jest komunikat informujący o utworzeniu
klucza dla ustanawianej sesji (box1). Umieszczana jest
w nim również pierwsza kopia klucza sesji. Szyfrowanie
komunikatu jest oparte na kluczu użytkownika
przechowywanym na serwerze.
10.
Działanie Kerberos V5cz.2
● Druga kopia klucza sesji trafia do kolejnego komunikatu
(box2), określanego nazwą bilet (ang. ticket). W
komunikacie tym zawarty jest identyfikator określający
nazwę użytkownika inicjującego komunikację.
Szyfrowanie komunikatu jest oparte o klucz usługi.
● Oba komunikaty są przesyłane użytkownikowi.
● Użytkownik odbiera skierowaną do niego wiadomość
przy użyciu własnego klucza prywatnego. Otrzymuje w
ten sposób bezpiecznie przesłany klucz sesji.
11.
Działanie Kerberos V5cz.3
● Użytkownik musi w kolejnym kroku utworzyć trzeci
komunikat, wartość uwierzytelniająca (ang.
authenticator). Jego podstawową zawartością jest
określenie bieżącego czasu.
● Zarówno bilet, jak i wartość uwierzytelniająca są
przesyłane do serwera danych w celu weryfikacji
użytkownika.
● Serwer danych otwiera oba komunikaty. Bilet jest
otwierany przy użyciu klucza prywatnego serwera.
Odczytuje on z niego klucz sesji. Przy jego użyciu
otwierana jest wartość uwierzytelniająca. Pozwala ona
określić czas trwania operacji.
12.
Działanie Kerberos V5cz.4
● Opcjonalnie, użytkownik może wymagać również weryfikacji
tożsamości serwera danych. W tym celu serwer umieszcza
znacznik czasu z komunikatu wartości uwierzytelniającej w
nowym komunikacie. Dołącza do niego również identyfikator
określający jego nazwę. Dane są szyfrowane przy użyciu
klucza sesji i zwracane użytkownikowi.
● Użytkownik otwiera zwrotny komunikat uwierzytelniający
przy użyciu klucza sesji, sprawdza poprawność nazwy
serwera danych. Dalsze transmisje będą już szyfrowane
przy użyciu utworzonego dla pojedynczej sesji klucza.
13.
Korzystanie z usługKerberos
● Użytkownik:
– przeźroczyste, wygodne i bezpieczne
● Programista – kerbalizator aplikacji ;-)
– najlepiej implementować wykorzystując GSS API
● Administrator:
– konieczność skonfigurowania stacji klienckich i instalacji
oprogramowania do zarządzania biletami
– konfiguracja serwera i serwerów usług
– duża rola serwera, jeśli serwer KDC padnie – problemy
z działaniem sieci
14.
Java Generic SecurityServices API
● Wysokopoziomowe GSS API zapewnia:
– poufność przekazu
– integralność przekazu
– autentykacja
● GSS opiera się o poniższe elementy:
– GSSName – identyfikuje uczestników komunikacji
– GSSCredential – dowód potwierdzający tożsamość
– GSSContext – bezpieczna sesja