Grzegorz Andruszkiewicz
Kerberos (The Kerberos Authentication Service)

Jest to protokół komunikacji sieciowej zapewniający:
  • uwierzytelnianie przez sieć.
  • szyfrowanie tylko algorytmami z kluczem symetrycznym (w rozszerzeniach korzysta się czasami z szyfrowania z kluczem prywatnym/publicznym).

    Został opracowany w MIT na potrzeby projektu Athena, a potem zyskał popularność i (z pewnymi zmianami) jest wykorzystywany we wszystkich ważniejszych systemach operacyjnych (np. Windows 2000, Linux, Solaris)

    Postaram się wyjaśnić działanie Kerberos w kilku krokach, opisując kolejno poszczególne aspekty jego działania. Opis ten będzie schematyczny, oderwany od konkretnych implementacji.

    Protokół uwierzytelniania przez sieć

    Łatwe rozwiązanie:
    Każda para klient - serwer, która współpracuje, współdzieli jeden klucz.


    (C) Grzegorz Andruszkiewicz

    Wady tego rozwiązania:
  • bardzo duża liczba kluczy niepotrzebnie pamiętanych.
  • trudność zmiany konfiguracji systemu (np. dołączenia serwera, etc.).

    Rozwiązanie:
    Dodanie osoby trzeciej (oddzielnego serwera) losującej klucz na czas trwania sesji
    tzw. KDC - (ang. Key Distribution Center) Centrum Dystrybucji Kluczy
    KDC nie przechowuje wylosowanych kluczy - zaraz po ich przekazaniu wymazuje je z pamięci.



    (C) Grzegorz Andruszkiewicz

    Teraz jeżeli pewien klient chce ustanowić połączenie z serwerem, musi zgłosić się najpierw do KDC i pobrać klucz sesji - ważny na pewien z góry określony czas klucz do szyfrowania wiadomości w komunikacji klient - serwer.


    Stałe klucze: (odpowiadające połączeniom na powyższym rysunku)
  • Wszystkie połączenia oparte są na kluczu znanym tylko obu stronom.
  • Klucze klientów generowane są z ich hasła (np. MD5).
  • Hasła serwerów generowane są losowo lub z hasła administratorów odp. zasobów.

    Protokół nie określa w jaki sposób ustanowić te stałe połączenia. Można skorzystać z algorytmów opartych na szyfrowaniu z kluczem prywatnym/publicznym, albo przenieść klucz "ręcznie".


    Dodatkowo postanowiono zwolnić serwery z obowiązku utrzymywania kluczy otwartych sesji. (Żeby pozbyć się problemów związanych z zarządzaniem bazą kluczy wszystkich otwartych sesji i tym samym zmniejszyć nakłady na bezpieczeństwo komunikacji po stronie serwera)

    Dlatego wprowadzamy bilet. W maksymalnym uproszczeniu KDC wydaje klientowi bilet uprawniający do korzystania z określonego serwera przez określony czas. Wysyłając coś do serwera klient musi dołączyć do wiadomości ten bilet, inaczej nie uzyska odpowiedzi. (Bo serwer nie będzie w stanie przesłać bezpiecznie informacji klientowi).


    Bilet:
  • Zostaje przydzielony przez KDC.
  • Jest zrozumiały tylko dla docelowego serwera.
  • Umożliwia przesłanie zaszyfrowanej odpowiedzi zrozumiałej tylko dla klienta.
    Bilet jest wiadomością przesyłaną jako ciąg bajtów. Ma następującą postać:
    • Caly bilet jest zaszyfrowany kluczem symetrycznym posiadanym tylko przez KDC i docelowy serwer - dlatego jest zrozumiały tylko dla docelowego serwera, nawet dla klienta stanowi "czarną skrzynkę".
    • Zawiera klucz sesji (dlatego umożliwia komunikację z klientem) i pewne dane dodatkowe, spełnijące funkcje:
      • Umożliwiają zorientowanie się serwerowi, że poprawnie odkodował klucz sesji - który jest ciągiem bitów i ma postać nieokreśloną
      • Zawierają dodatkowe informacje ułatwiające komunikację i uwierzytelnianie np. czas i nazwę klienta (szczegóły w odp. plikach RFC - patrz Bibliografia na końcu tego dokumentu).


    Na kolejnych dwóch rysunkach przyjąłem następujące oznaczenia:
  • Każdy klucz (przypomnę że korzystamy tylko z algorytmów z kluczem symetrycznym) charakteryzuje się innym kolorem i po tym go odróżniamy
  • Duże kolorowe prostokąty są zaszyfrowane. Do odszyfrowania potrzebny jest klucz tego właśnie koloru.
  • Każdy serwer i klient przechowuje (w ulotnej pamięci dostępnej tylko dla procesu obsługującego Kerberos) klucze pokazane jako małe kolorowe kwadraciki.


    (C) Grzegorz Andruszkiewicz

    Poszczególne kroki uwierzytelniania: (na kolorowo wiadomości zaszyfrowane kluczem odp. koloru)
  • Prośba KDC o bilet i kopię klucza sesji.
  • KDC odsyła klucz sesji zaszyfrowany z użyciem klucza klienta + bilet.
  • Bilet to klucz sesji + dod. informacje zaszyfrowany z użyciem klucza serwera.
  • Przy każdej komunikacji z serwerem wiadomości szyfrujemy kluczem sesji i dołączamy bilet.
  • Pierwszą wiadomością przesłaną do serwera jest UWIERZYTELNIACZ (ang. AUTHENTICATOR) - wiadomość służąca to uwierzytelnienia na serwerze

    Uwagi:
  • Bilet rzeczywiście jest zrozumiały tylko dla docelowego serwera.
  • Zawiera klucz więc umożliwia zaszyfrowanie odpowiedzi.
  • Serwer nie musi pamietać klucza.
  • Klucz sesji ma określony okres ważności (najczęściej 8 godzin).


    W rzeczywistości wprowadza się dodatkowe zabezpieczenie, ograniczające użycie stałego klucza do minimum.

    Dodajemy specjalny rodzaj biletu:
    Bilet na bilet (Ticket Granting Ticket) - bilet "wyższego rzędu" uprawniający do pobierania zwykłych biletów
    Oraz nowego pośrednika:
    Serwis Wydający Bilety - TGS Ticket Granting Server - wydaje zwykłe bilety na podstawie biletów "wyższego rzędu"
    .


    (C) Grzegorz Andruszkiewicz

    Teraz do KDC (nazywanego w niektórych źródłach Serwerem Uwierzytelniania (Authentication Server) zgłaszamy sie tylko raz po TGT, wymazujemy z pamięci nasz klucz stały (na schemacie nasz klucz stały jest w kółku). Po zwykłe bilety zgłaszamy się do TGS.

    Zwykle KDC i TGS są fizycznie połączone (wręcz w jeden proces).



    Niestety rozwiazanie to jest nieskalowalne
    .

    W praktyce wszystkie serwery dostępne poprzez mechanizmy KDC dzieli się na rozłączne grupy (ang. realms) - (serwer może być w dwóch grupach na raz, ale pod inną nazwą). Najczęściej te grupy pokrywają się z domenami sieciowymi. Są połączone hierarchicznie, np.:



    (C) Grzegorz Andruszkiewicz

    Żeby połączyć się z serwerem nie należącym do naszej grupy, od naszego lokalnego serwera wydającego bilety (TGS) dostajemy bilet na bilet (TGT) to TGS'a w sąsiedniej grupie. TGS w sąsiedniej grupie daje nam już zwykły bilet (jeżeli docelowy serwer znajduje sie w jego grupie) lub odsyła nas do kolejnego TGS'a.

    Z tego wynika, że połączenie z serwerem wymaga O(lg n) aplikacji o TGT w kolejnych TGS, przy zalożeniu że drzewo hierarchii grup jest zrównoważone (gdzie n oznacza liczbę serwerów).


    W następującym przykładzie naszą lokalną grupą jest SZJO i chcemy się połączyć z serwerem UW. Musimy wykonać 5 połączeń pośrednich:

    (C) Grzegorz Andruszkiewicz

    Dla najczęściej wykonywanych połączeń można utworzyć skrót (teraz łączymy się z naszej lokalnej grupy SZJO z JASIO) :


    (C) Grzegorz Andruszkiewicz

    Teraz wystarczą nam trzy połaczenia pośrednie.



    Uwagi dodatkowe dotyczące Kerberos:
      Jest to tylko protokól uwierzytelniania, a nie autoryzacji! Dla autoryzacji zostało zostawione specjalne pole w strukturze AUTHENTICATOR. Zostały dodane nowe funkcjonalności gdy korzystamy z serwerów pośrednich. Bilet TGT (bilet na bilet) może być jeszcze "wyższego poziomu" i może zezwalać serwerom, z którymi się kontaktujemy bezpośrednio, na pobieranie biletów w naszym imieniu. Rozrózniamy dwa rodzaje takich biletów:
      • proxy - serwer nie może ubiegać się o TGT
      • forward - serwer może ubiegać się o TGT
      Jeżeli ważność klucza jest zbyt krótka - jest możliwość użycia kluczy odnawialnych (renewable keys) - odnowienie klucza jest prostsze niż pobranie nowego biletu, a zapewnia bezpieczeństwo (że nikt nie zdąży złamać szyfru zanim nie wymienimy klucza na nowy).




    Dodatkowo obowiązkiem Algorytmu szyfrowania jest

  • zapewnić bezpieczeństwo
  • wykrywać naruszenie danych

    Jeżeli algorytm nie spełnia drugiego punktu to osoba implementująca musi dołączyć sume kontrolną (dzis CBC DES + MD5)

    Ten warunek jest konieczny do zabezpieczenia się przed modyfikowaniem naszych danych, a nie tylko przed ich odczytaniem przez osobę trzecią.


    BIBLIOGRAFIA

    Proste opisy:

    www.isi.edu/gost/brian/security/kerberos.html
    web.mit.edu/is/help/kerberos/whatis.html
    web.mit.edu/kerberos/WWW/

    Strony zawierające linki do innych dokumentów:

    web.mit.edu/kerberos/WWW/papers.html
    www.isi.edu/gost/info/kerberos/documentation.html

    Dokładny opis działania oraz porównanie wersji 4 i 5:

    ftp://athena-dist.mit.edu/pub/kerberos/doc/krb_evol.PS

    Dokumentacja techniczna:

    rfc1510 - The Kerberos Network Authentication Service
    rfc1964 - Kerberos v5 GSS-API