Kerberos: protokół uwierzytelniania




         Tomasz Bąk, zima 2004
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
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
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
Pojęcia związane z Kerberosem
●   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
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
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)
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
Działanie Kerberos V5 cz.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.
Działanie Kerberos V5 cz.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.
Działanie Kerberos V5 cz.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.
Działanie Kerberos V5 cz.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.
Korzystanie z usług Kerberos
●   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
Java Generic Security Services 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
To juz koniec, pytania?

Kerberos

  • 1.
  • 2.
    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
  • 15.