Próba połączenia

W odpowiedzi na próbę zalogowania się użytkownika do sieci serwer RADIUS generuje zapytanie o dane użytkownika i hasło. W wyniku skonfrontowania danych przedstawionych przez użytkownika z tymi, które serwer odczyta z repozytorium serwera AAA, żądanie dostępu jest akceptowane lub odrzucane. O ile zostało to przewidziane w procedurze logowania, serwer RADIUS może zażądać podania dodatkowych informacji, np. popularnego w aplikacjach WWW wprowadzenia znaków znajdujących się na obrazku wysłanym do użytkownika - w celu ominięcia automatów.

Choć RADIUS-owi towarzyszy otoczka bezpieczeństwa, jego implementacje posiadają wady i błędy logiczne w konfiguracji konkretnej instalacji, pozwalające na przezwyciężenie zasieków. Ataków jest sporo. Można tu wymienić np. atak hasło-użytkownik, który umożliwia zmodyfikowanie pakietu access request, na podstawie odpowiedzi otrzymanej po poprzedniej nieudanej próbie, zawierającej wartość MD5 z sumy współdzielonego klucza (shared secret) i klucza wygenerowanego przez serwer RADIUS (request authenticator). Skrypty pozwalające na atak typu bruteforce przeciętny administrator jest w stanie napisać od ręki. Odniesie on skutek, jeśli w systemie nie przewidziano blokad dopuszczających np. trzy próby logowania, a następne trzy dopiero za 15 minut.

Istnieją także inne metody ataków na implementacje RADIUS-a, spowodowane głównie przewidywalnością działania algorytmu MD5, a także ochroną hasła relatywnie prostym szyfrem strumieniowym (RC4). Możliwe są także ataki bardziej zaawansowane, np. włączenie do sieci własnego serwera RADIUS w celu przechwytywania listy pakietów request authenticator. Na ich podstawie można stworzyć fałszywe pakiety access reject i użyć ich do ataku DoS na właściwy serwer RADIUS, a po jego wyłączeniu lub restarcie dokonać próby wejścia do sieci.

Popularność protokołu RADIUS wzrosła po upowszechnieniu się sprzętu WLAN. Każdy z producentów sięga po dokumentację, po czym przygotowuje własną implementację - doskonałą często tylko na papierze. Ponadto trzeba pamiętać, że bez względu na różne zabiegi "utwardzające", podstawy teoretyczne protokołu RADIUS pozostają niezmienne. Być może przyszłe wersje standardu będą bardziej precyzyjne lub będą przewidywać kroki, których uwzględnienie będzie podwyższać bezpieczeństwo każdej instalacji. Na to trzeba jednak czasu.

Bez porównania

Porównanie protokołów Kerberos i RADIUS, choć kuszące, tak naprawdę nie ma sensu, ponieważ każdy z nich powstał dla innych zastosowań. Kerberos to protokół wielousługowych sieci lokalnych, zaś RADIUS - jednousługowych, sieci dostępowych. Jeśli ich specyfika nie będzie "naciągana", a także, gdy uwzględnione zostaną wnioski płynące z dotychczasowego funkcjonowania ich poszczególnych implementacji, nic złego nie powinno się przydarzyć. Najbardziej labilnym elementem tej układanki jest, jak zwykle, człowiek - przede wszystkim projektant sieci.

Kerberos pod okiem Microsoftu będzie się dalej rozwijać, zwłaszcza w dziedzinie uwierzytelniania stacji klienckich Windows. RADIUS, mając wsparcie Cisco i innych producentów sprzętu sieciowego, także nie pozostanie w tyle. Być może z biegiem czasu na bazie obu powstanie nowy, kompleksowy system uwierzytelniania. Kto wie, być może nie będzie to nowy protokół uwierzytelniania, lecz "nadbudowa", pozwalająca na przenoszenie informacji o uwierzytelnieniu i uprawnieniach pomiędzy wieloma systemami, jak ma to miejsce w WS-Security i WS-Federation?