Kerberosprotokół uwierzytelniania i autoryzacji w sieci komputerowej z zastosowaniem centrum dystrybucji kluczy, zaprojektowany w Massachusetts Institute of Technology (MIT).

Powstało też wiele interfejsów programistycznych pozwalających wbudowywać mechanizmy bezpieczeństwa dostarczane przez serwer Kerberos do aplikacji. Jednym z nich jest interfejs w języku Java nazwany General Security Service.

Historia i rozwój

Instytut Techniczny Massachusetts stworzył Kerberosa w celu ochrony usług sieciowych dostarczanych w ramach projektu Athena. Protokół bazuje na opracowanym wcześniej protokole kluczy symetrycznych, stworzonym przez Rogera Needhama i Michaela Schroedera. Istnieje kilka jego wersji, przy czym wersje od 1 do 3 występowały jedynie wewnętrznie w MIT.

Steve Miller i Clifford Neuman, pierwsi projektanci czwartej wersji Kerberosa, opublikowali ją w latach osiemdziesiątych, mimo że pierwotnie planowali ją wdrożyć dla projektu Athena.

Wersja 5, opracowana przez Johna Kohla i Clifforda Neumana, wystąpiła jako standard RFC 1510 ↓ w 1993 (uznana za przestarzałą po opracowaniu RFC 4120 ↓ w 2005). Głównym powodem implementacji tej wersji było zlikwidowanie ograniczeń oraz problemów z bezpieczeństwem występujących w wersji 4.

Władze w Stanach Zjednoczonych sklasyfikowały Kerberosa jako „dodatkowe wyposażenie wojskowe” i zakazały jego eksportu, ponieważ używał on algorytmu Data Encryption Standard (DES) (wraz z kluczami 56-bitowymi).

Implementacja „nieamerykańskiej” czwartej wersji Kerberosa (KTH-KRB) została stworzona w Królewskim Instytucie Technicznym w Sztokholmie, sprawiła, że system ten stał się dostępny poza granicami Stanów Zjednoczonych, zanim władze amerykańskie zmieniły politykę eksportu kryptografii (około roku 2000). Szwedzka wersja bazowała na edycji zwanej eBones. Z kolei eBones bazował na eksportowanej edycji z MIT, która pozbawiona była zarówno funkcji szyfrujących, jak i odwołań do nich.

W 2005 grupa Internet Engineering Task Force (IETF) zaktualizowała specyfikacje. Zmiany dotyczyły m.in.:

  • specyfikacji szyfrowania i sum kontrolnych (RFC 3961 ↓)
  • szyfrowania za pomocą Advanced Encryption Standard (AES) dla Kerberosa 5 (RFC 3962 ↓)
  • nowej edycji specyfikacji Kerberosa 5, nazwanej The Kerberos Network Authentication Service (V5) (RFC 4120 ↓). Ta wersja wyparła standard RFC 1510 ↓, wyjaśnia aspekty protokołu i przeznaczenie w sposób bardziej jasny i szczegółowy.
  • nowej edycji specyfikacji GSS-API (ang. generic security services application program interface), nazwanej Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2 (RFC 4121 ↓).

MIT stworzył ogólnodostępną implementację Kerberosa, której prawa autorskie były podobne do używanych w ramach BSD. W 2007, MIT powołał konsorcjum Kerberosa w celu wsparcia dalszej implementacji protokołu. Sponsorami były m.in. Oracle, Apple Inc., Google, Microsoft, Centrify Corporation, TeamF1 Inc., a także instytucje akademickie (Królewski Instytut Techniczny, Uniwersytet Stanforda, MIT).

Opis protokołu

Najpierw następuje uwierzytelnienie klienta na serwerze (ang. authentication serverAS), który przesyła nazwę użytkownika do centrum dystrybucji kluczy (KDC).

KDC tworzy unikatowy identyfikator (ang. ticket-granting ticketTGT), szyfruje go za pomocą tajnego klucza TGS (ang. Ticket Granting ServerTGS) i zwraca zaszyfrowaną wartość do stacji użytkownika.

Logowanie klienta

  1. Użytkownik wprowadza login i hasło na maszynie klienta. Inne mechanizmy logowania, jak np. pkinit (RFC 4556 ↓) pozwalają na użycie kluczy publicznych zamiast hasła.
  2. Klient konwertuje hasło na klucz symetryczny. Używany jest tutaj wbudowany klucz lub jednokierunkowa funkcja haszująca, w zależności od użytych narzędzi kryptograficznych.

Uwierzytelnienie

  1. Klient wysyła swoje ID w postaci jawnej wiadomości na serwer uwierzytelniający (AS).
  2. AS generuje klucz tajny, konwertując hasło użytkownika znalezione w bazie danych
  3. AS sprawdza obecność klienta w bazie. Jeżeli się tam znajduje, AS wysyła 2 wiadomości zwrotne:
    • Wiadomość A: Klucz sesji klienta, zaszyfrowany tajnym kluczem klienta
    • Wiadomość B: ticket-granting-ticket – zawiera ona ID klienta, adres jego sieci i klucz sesji klienta, zaszyfrowane tajnym kluczem TGS.
  4. Gdy klient otrzyma wiadomości A oraz B, rozpoczyna odszyfrowywanie wiadomości A za pomocą tajnego klucza wygenerowanego z hasła użytkownika. Jeżeli hasło wprowadzone przez użytkownika nie odpowiada jego hasłu z bazy AS, tajny klucz użytkownika będzie inny i tym samym nie będzie on w stanie odszyfrować wiadomości A. Mając prawidłowy klucz, klient odszyfruje wiadomość. Ten klucz sesji będzie używany do dalszej komunikacji. Klient nie jest w stanie odszyfrować wiadomości B, ponieważ jest ona zaszyfrowana tajnym kluczem TGS.

Autoryzacja

  1. Wysyłając zapytanie o wykonanie usługi, klient wysyła do TGS następujące wiadomości:
    • wiadomość C: Zawiera ona TGT z wiadomości B oraz ID oczekiwanej usługi.
    • wiadomość D: Uwierzytelnienie (zawierające ID klienta i znacznik czasu), zaszyfrowane za pomocą klucza sesji klienta/TGS.
  2. Po uzyskaniu wiadomości C oraz D, TGS „wytwarza” wiadomość B na podstawie wiadomości C. Odszyfrowuje wiadomość B za pomocą tajnego klucza TGS. Tym samym tworzony jest klucz sesji klienta/TGS. Przy użyciu tego klucza, TGS odszyfrowuje wiadomość D (uwierzytelnienie) i wysyła 2 następujące wiadomości do klienta:
    • Wiadomość E: Zawiera ona ID klienta, jego adres sieciowy, okres ważności oraz klucz sesji klienta/serwera. Całość zaszyfrowana jest tajnym kluczem usługi.
    • Wiadomość F: klucz sesji klienta/serwera, zaszyfrowany kluczem sesji klienta/TGS

Zapytanie użytkownika

  1. Po otrzymaniu wiadomości E oraz F z TGS, klient ma wystarczającą ilość danych, by zostać uwierzytelnionym na serwerze usług (ang. service serverSS). Klient łączy się z SS i wysyła następujące wiadomości:
    • Wiadomość E z poprzedniego kroku
    • Wiadomość G – nowe narzędzie uwierzytelnienia, zawierające ID klienta, znacznik czasu. Zaszyfrowane kluczem sesji klienta/serwera.
  2. SS odszyfrowuje dane swoim własnym tajnym kluczem, by pozyskać klucz sesji klienta/serwera. Za pomocą klucza sesji, SS odszyfrowuje wiadomość G i wysyła poniższą wiadomość do klienta, by potwierdzić jego tożsamość i zgodę na wykonanie usługi:
    • Wiadomość H: Znacznik czasu, znajdujący się we wiadomości uwierzytelniającej klienta, zaszyfrowany kluczem sesji klienta/serwera.
  3. Klient odszyfrowuje wiadomość z potwierdzeniem za pomocą klucza sesji klienta/serwera. Ponadto sprawdza, czy znacznik czasu jest prawidłowy. Jeżeli jest, wówczas klient może uznać serwer za wiarygodny i może rozpocząć wysyłanie zapytań o usługi na ten serwer.
  4. Serwer rozpoczyna wykonywanie usług, o których wykonanie poprosi klient.

Wady i ograniczenia

  • Wymagana jest ciągła dostępność centralnego serwera. Gdy Kerberos będzie nieaktywny, nowi użytkownicy nie będą mieli możliwości logowania. Te skutki można złagodzić, używając kilku serwerów Kerberosa oraz alternatywnych mechanizmów uwierzytelniających.
  • Kerberos posiada restrykcyjne ograniczenia czasowe, co oznacza że zegary hostów muszą być zsynchronizowane zgodnie ze skonfigurowanymi limitami. Jeżeli zegar hosta nie będzie odpowiednio zsynchronizowany z serwerem Kerberosa, uwierzytelnienie się nie powiedzie. Według domyślnej konfiguracji[1], różnica czasu powinna wynosić nie więcej niż 5 minut.
  • Protokół administracyjny nie posiada własnego standardu i różni się w zależności od implementacji serwerów. Zmiany haseł opisano w RFC 3244 ↓.
  • W przypadku symetrycznego szyfrowania (Kerberos może pracować zarówno z użyciem symetrycznych oraz asymetrycznych kluczy) – jako że wszelkie procesy uwierzytelniające są pod kontrolą centrum dystrybucji kluczy (KDC) – w razie zagrożenia infrastruktury uwierzytelniającej haker będzie mógł podszyć się pod dowolnego użytkownika.
  • Każda usługa sieciowa wymagająca innej nazwy hosta, będzie potrzebowała własnego zestawu kluczy.
  • Kerberos wymaga, aby wszystkie konta użytkowników, klienci oraz usługi na serwerze miały zaufane powiązanie z serwerem tokenowym Kerberosa (Wszystkie muszą być w tej samej domenie Kerberosa lub w domenach, mających zaufane powiązania pomiędzy sobą). Kerberosa nie można użyć w przypadku, gdy użytkownik chce skorzystać z usług za pomocą nieznanych/niezaufanych klientów, gdzie usługa uwierzytelniająca zazwyczaj „nie posiada” wiedzy odnośnie do systemu klienta, z którego korzysta użytkownik.
  • Fakt, iż wymagany jest zaufany klient, sprawia, iż tworzenie konkretnych środowisk (np. osobne domeny dla środowiska testowego oraz produkcyjnego) jest utrudnione: Albo należy utworzyć powiązanie pomiędzy domenami, które będzie zapobiegać rozdzieleniu domen środowiskowych lub należy utworzyć dodatkowych klientów dla poszczególnego środowiska.

Luki w zabezpieczeniach

Algorytm DES może być używany wraz z Kerberosem, lecz już nie jest obecnie stosowany jako standard, gdyż uznany jest jako słaby szyfr[2]. Luki w zabezpieczeniach występują w wielu produktach, w których zastosowana jest implementacja Kerberosa, ponieważ nie były one aktualizowane w celu używania nowszych szyfrów od DES’a, takich jak AES.

W listopadzie 2014, Microsoft udostępnił aktualizację (MS14-068) w celu skorygowania wady, pozwalającej na nieprawidłowe korzystanie w implementacji Centrum Dystrybucji Kluczy (KDC) Kerberosa (dla systemu Windows)[3]. W wyniku istnienia tej luki, użytkownicy mogli rzekomo „zwiększyć” swoje przywileje i tym samym mogli ich nadużywać.

Przypisy

  1. Clock Skew – Kerberos V5 System Administrator’s Guide [online], web.mit.edu [dostęp 2016-01-25].
  2. RFC 6649 ↓.
  3. Details emerge on Windows Kerberos vulnerability | ZDNet [online], www.zdnet.com [dostęp 2017-11-14] (ang.).

Linki zewnętrzne

  • Strona domowa projektu Kerberos
  • The Kerberos FAQ
  • Implementacja Heimdal protokołu Kerberos 5. pdc.kth.se. [zarchiwizowane z tego adresu (2006-03-14)].
  • Shishi – wolna implementacja systemu Kerberos 5
  • J. Kohl, C. Neuman, The Kerberos Network Authentication Service (V5), RFC 1510, IETF, wrzesień 1993, DOI: 10.17487/RFC1510, ISSN 2070-1721, OCLC 943595667 (ang.).
  • M. Swift, J. Trostle, J. Brezak, Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols, RFC 3244, IETF, luty 2002, DOI: 10.17487/RFC3244, ISSN 2070-1721, OCLC 943595667 (ang.).
  • K. Raeburn, Encryption and Checksum Specifications for Kerberos 5, RFC 3961, IETF, luty 2005, DOI: 10.17487/RFC3961, ISSN 2070-1721, OCLC 943595667 (ang.).
  • K. Raeburn, Advanced Encryption Standard (AES) Encryption for Kerberos 5, RFC 3962, IETF, luty 2005, DOI: 10.17487/RFC3962, ISSN 2070-1721, OCLC 943595667 (ang.).
  • C. Neuman i inni, The Kerberos Network Authentication Service (V5), RFC 4120, IETF, lipiec 2005, DOI: 10.17487/RFC4120, ISSN 2070-1721, OCLC 943595667 (ang.).
  • L. Zhu, K. Jaganathan, S. Hartman, The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2, RFC 4121, IETF, lipiec 2005, DOI: 10.17487/RFC4121, ISSN 2070-1721, OCLC 943595667 (ang.).
  • L. Zhu, B. Tung, Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), RFC 4556, IETF, czerwiec 2006, DOI: 10.17487/RFC4556, ISSN 2070-1721, OCLC 943595667 (ang.).
  • L. Hornquist Astrand, T. Yu, Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos, BCP 179, RFC 6649, IETF, lipiec 2012, DOI: 10.17487/RFC6649, ISSN 2070-1721, OCLC 943595667 (ang.).

Witaj

Uczę się języka hebrajskiego. Tutaj go sobie utrwalam.

Źródło

Zawartość tej strony pochodzi stąd.

Odsyłacze

Generator Margonem

Podziel się