Upload
kamran
View
142
Download
3
Embed Size (px)
DESCRIPTION
Protokół RADIUS i jego zastosowania. Maja Górecka-Wolniewicz UCI UMK. Standard RADIUS. RFC 2865 – Remote Authentication Dial In User Service, zastąpił specyfikację RFC 2138 Określa sposób dostarczenia metod: uwierzytelniania, autoryzacji i rozliczania (AAA) - PowerPoint PPT Presentation
Citation preview
Tomasz Wolniewicz UCI UMK
Seminarium eduroam – UMK, 16-17.03.2006
Maja Górecka-Wolniewicz
UCI UMK
Protokół RADIUS i jego zastosowania
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK2
• RFC 2865 – Remote Authentication Dial In User Service, zastąpił specyfikację RFC 2138
• Określa sposób dostarczenia metod: uwierzytelniania, autoryzacji i rozliczania (AAA)
• Opcjonalny w IEEE 802.1x, rekomendowany • Podstawowe pojęcia:
– uwierzytelnianie (authentication)– autoryzacja (authorization)– użytkownik, suplikant (supplicant)– klient RADIUS, NAS, autentykator (Network Access Server) – serwer uwierzytelniania (authentication server)– sesja (session) – rozliczanie (accounting)
Standard RADIUS
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK3
Własności specyfikacji RADIUS
• Model klient/serwer– komunikacja zlecenie-odpowiedź
• Bezpieczeństwo sieci– stosowanie wspólnego klucza tajnego (shared secret)– bezpieczne przekazywanie haseł
• Elastyczne metody uwierzytelniania– EAP jako protokół transportujący dowolne protokoły
uwierzytelniania
• Łatwa rozszerzalność protokołu – spójna definicja elementów protokołu bazująca na trójce:
atrybut, długość, wartość
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK4
RADIUS – protokół transakcyjny
• Konieczność współpracy z alternatywnym serwerem - w przypadku niedostępności głównego serwera– trzeba przechowywać kopię zlecenia na poziomie aplikacji w
celu retransmisji– muszą być zaimplementowane specyficzne dla aplikacji
limity czasu do retransmisji (timeouty)
• Wymagania dotyczące obsługi nie są zgodne z implementacją dostarczaną przez TCP– nie jest wymagane wykrywanie strat danych– nie są potrzebne potwierdzenia, retransmisje TCP– protokół TCP wprowadziłby duże opóźnienia
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK5
RADIUSimplementacja UDP
• Bezstanowa natura protokołu– duża dynamika zjawisk, bez potrzeby przywracania
stanu, wyeliminowanie specjalnej obsługi zdarzeń dotyczących utraconych połączeń
• Dzięki oparciu protokołu RADIUS na UDP łatwo mogą być tworzone implementacje– początkowo serwery jednowątkowe– przejście na wielowątkowość było prostsze dzięki
stosowaniu UDP
• Porty UDP: 1812 (authn), 1813 (accounting), 1814 (proxy)
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK6
Pakiety RADIUS
• Struktura pakietu
Kod 1B
Identyfikator 1B
Rozmiar pakietu 2B Autentykator
łącznie 16B
Atrybuty łącznie nB
..........
..........
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK7
Pakiety RADIUS
• Kod
1 Access-Request 2 Access-Accept 3 Access-Reject 4 Accouning-Request 5 Accouning-Response 11 Access-Challenge 12 Status-Server (eksperymentalny) 13 Status-Client (eksperymentalny)255 Reserved
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK8
Pakiety RADIUS
• Identyfikator – 1B, unikatowy identyfikator w celu dopasowania par zlecenie-odpowiedź
• Rozmiar pakietu – 2B, całkowity rozmiar komunikatu RADIUS, łącznie z polem rozmiaru; dozwolone wartości od 20 do 4096B
• Autentykator – 16B, informacja używana do uwierzytelnienia odpowiedzi z serwera, a także jest stosowana w algorytmie ukrywania hasła (użycie shared-secret)– w pakiecie Access-Request autentykator zlecenia– w pakiecie Access-Accept/Reject autentykator odpowiedzi
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK9
Access-Request
• Pakiet inicjujący komunikację – AP (klient RADIUS) zgłasza do serwera RADIUS chęć dostępu– POWINIEN zawierać atrybut User-Name– MUSI zawierać atrybut NAS-IP-Address lub NAS-
Identifier, lub oba atrybuty– MUSI zawierać albo User-Password, albo CHAP-
Password, albo State– POWINIEN zawierać NAS-Port lub NAS-Port-Type– MOŻE zawierać dodatkowe atrybuty
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK10
Access-Accept/ Access-Reject
• Access-Accept– pole identyfikatora MUSI zgadzać się z polem
identyfikatora w odpowiednim zleceniu– pole autentykatora MUSI zawierać poprawną
odpowiedź dla dopasowanego zlecenia
• Access-Reject– MOŻE zawierać atrybuty Reply-Message
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK11
Access-Challenge
• MOŻE zawierać atrybuty Reply-Message• MOŻE zawierać jeden atrybut State• MOŻE zawierać atrybuty Vendor-Specific, Idle-
Timeout, Session-Timeout, Proxy-State• Żadne inne atrybuty nie są dozwolone• Pole identyfikatora MUSI zgadzać się z polem
identyfikatora w odpowiednim zleceniu• Pole autentykatora MUSI zawierać poprawną
odpowiedź dla dopasowanego zlecenia
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK12
Atrybuty
• Atrybuty przenoszą specyficzne informacje dotyczące procesu uwierzytelniania, autoryzacji i konfiguracji
• Atrybut może mieć wiele wystąpień• Reprezentacja atrybutu
Typ 1B
Rozmiar 1BWartość 0-nB
atrybuty mają przypisane ident. numeryczne
liczony łącznie z polem typu i rozmiaru
5 typów: tekst UTF-8, napis, adres, liczba, czas
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK13
Przykładowe atrybuty 1 User-Name Nazwa użytkownika w postaci tekstu UTF-8,
identyfikatora sieciowego lub nazwy wyróżnionej (DN)
2 User-Password Hasło użytkownika (ukryte) lub odpowiedź na Access- Challenge
3 CHAP-Password Odpowiedź dostarczona w protokole CHAP 4 NAS-IP-Address Adres IP AP-a
...............................................................................24 State Wysyłany przez serwer do klienta w Access-
Challenge, musi zostać przesłany niezmieniony przez klienta do serwera w Access-Request
25 Class Wysyłany przez serwer do klienta w zleceniu Access-Accept, powinien zostać przesłany
niezmieniony do serwera w pakiecie Accounting-Request
Łącznie w RFC2865 zdefiniowano 43 typy w zakresie 1-63, zakres 40-59 przeznaczono na atrybuty accountingowe
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK14
Atrybut Vendor-Specific
• Wprowadzony w celu możliwości wsparcia własności specyficznych dla określonego sprzętu/dostawcy – atrybut o typie 26– atrybut zawierający podatrybuty
• W polu wartości atrybutu podpola:– Vendor-Id – 4B, najwyższy bajt 0, pozostałe to kod
dostawcy zdefiniowany w Assigned Numbers (RFC 1700)– napis – 1 lub więcej sekwencji bajtów w postaci:
• typ dostawcy (Vendor type), 1B• rozmiar (Vendor length), 1B – rozmiar następnego
podpola+2• atrybut (Vendor data, Attribute-Specific field) w postaci
nazwa=wartość
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK15
Atrybuty Vendor-Specific Microsoft
• Definicja: RFC 2548• Wsparcie dla aplikacji Windows związane z usługami
dial-up i protokołem RADIUS– obsługa protokołu MS-CHAP, MS-CHAPv2
• Przykładowe atrybuty:– MS-CHAP-Challange, MS-CHAP-Response, MS-CHAP-Domain,
MS-CHAP2-Success, MS-CHAP2-Response
• Atrybuty związane z Microsoft Point-To-Point Encryption (MPPE), umieszczane w Access-Accept– MS-MPPE-Send-Key – zawiera klucz przeznaczony do
wysyłania bezpiecznych pakietów z AP do suplikanta– MS-MPPE-Recv-Key – zawiera klucz przeznaczony do
szyfrowania pakietów otrzymanych przez AP z suplikanta– stosowane do tworzenia materiału kryptograficznego
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK16
Rozszerzenia protokołu RADIUS
• RFC 2869, RADIUS Extensions– rozszerzenia wprowadzają nowe, specyficzne dla
operacji atrybuty– wsparcie aktualizacji rozliczeniowych – Interim
Accounting Updates• atrybut Acct-Interim-Interval
– wsparcie Apple Remote Access Protocol (ARAP)– wsparcie EAP-a
• przenoszenie w pakietach Radius pakietów EAP: atrybuty EAP-Message i Message-Authenticator
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK17
Accounting- informacje rozliczeniowe
• RFC 2866, RADIUS Accounting– dostarczanie informacji rozliczeniowej z urządzenia do
serwera RADIUS– w protokole RADIUS zdefiniowano pakiety Accounting-
Request i Accounting-Response– RFC definiuje atrybuty, których typy zarezerwowano w
oryginalnej specyfikacji
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK18
Accounting- informacje rozliczeniowe
40 Acct- Status-Type początek/koniec sesji (start/stop/interim-update
accounting-on/off)
41 Acct-Delay-Time ile sekund klient próbował przesłać rekord
42 Acct-Input-Octets
43 Acct-Output-Octets
44 Acct-Session-Id unikatowy identyfikator sesji
45 Acct-Authentic sposób uwierzytelnienia (NAS, RADIUS)
46 Acct-Session-Time
47 Acct-Input-Packets
48 Acct-Output-Packets
49 Acct-Terminate-Cause przyczyna końca sesji, np. Idle-Timeout, NAS error
50 Acct-Multi-Session-Id
51 Acct-Link-Count
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK19
RADIUS - działanie
• Jeśli urządzenie sieciowe (NAS) jest klientem RADIUS, to użytkownik musi przekazać klientowi dane uwierzytelniania
• NAS przesyła pakiet Access-Request do serwera RADIUS – w zleceniu musi pojawić się User-Name itd.
• Gdy nie pojawia się odpowiedź– NAS ponawia przesyłanie do tego samego serwera, – NAS przekazuje zlecenie do serwera alternatywnego
• Serwer RADIUS po odebraniu zlecenia Access-Request sprawdza wiarygodność klienta – wspólny klucz tajny (shared secret) służy do
uwierzytelniania transakcji klient-serwer– wspólny klucz tajny NIGDY nie jest przesyłany przez sieć
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK20
RADIUS - działanie
• Serwer RADIUS w oparciu o lokalne metody uwierzytelniania sprawdza uprawnienia użytkownika
• W przypadku negatywnego wyniku kontroli serwer odpowiada pakietem Access-Reject
• Serwer może przekazać do klienta pakiet (odpowiedź) Access-Challenge
• Po otrzymaniu pakietu Access-Challenge klient ponownie wysyła Access-Request (z nowym ID)
• Pozytywny wynik uwierzytelnienia kończy odpowiedź Access-Accept
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK21
Mechanizm challenge/response
• challenege – wyzwanie: serwer wysyła liczbę losową
• Klient musi na podstawie tej liczby wyliczyć response - odpowiedź, którą przekazuje w kolejnym zleceniu Access-Request – odpowiedź pojawia się w atrybucie User-Password
• Zleceniu Access-Challenge może towarzyszyć atrybut State, który MUSI być transmitowany przezroczyście
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK22
Funkcjonalność proxy w protokole RADIUS
• Serwer RADIUS dostaje z urządzenia NAS zlecenie uwierzytelnienia
• Natychmiast przekazuje zlecenie do innego zdalnego serwera RADIUS
• Odbiera odpowiedź ze zdalnego serwera, weryfikuje poprawność odpowiedzi na podstawie wspólnego hasła i pola autentykatora i przekazuje odpowiedź klientowi
• Typowe zastosowanie – roaming• Wybór serwera na ogół bazuje na wartości realm,
określanej na podstawie identyfikatora sieciowego
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK23
Proxy RADIUS
• Zastosowanie atrybutu Proxy-State– serwer przekazujący zlecenia MUSI przezroczyście
transmitować atrybuty Proxy-State, nie może zmieniać ich kolejności
– serwer przed przekazaniem zlecenia może dodać atrybut Proxy-State, przy czym MUSI umieścić ten atrybut na końcu, za wszystkimi innymi atrybutami tego typu
– jeśli serwer umieścił atrybut Proxy-State, to po otrzymaniu odpowiedzi MUSI go usunąć (usunąć ostatni atrybut Proxy-State w pakiecie)
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK24
Proxy RADIUS
• Serwer przed przekazaniem zlecenia deszyfruje atrybut User-Password używając wspólnego klucza tajnego A i B
• Serwer szyfruje User-Password stosując wspólny klucz tajny B i C
• Pole “authenticator” jest stosowane do weryfikacji pakietów – pakiety negatywnie zweryfikowane są kasowane
• Jeden serwer może pełnić funkcję proxy i remote, może być serwerem proxy dla wielu domen (realms) itd.
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK25
802.1x w sieci bezprzewodowej
• Pojęcie portów logicznych– wykorzystanie adresów MAC suplikanta i AP-a do
stworzenia kanału transmisji– suplikant łączy się z AP zanim są dostępne klucze
dynamiczne (własność AP zw. open authentication)– porty niekontrolowane i kontrolowane
• Zarządzanie kluczami– 802.1x nie wymaga WEP-a, ani innego mechanizmu
szyfrującego, ale pozwala na użycie mechanizmów szyfrujących
– 802.1x posiada mechanizm dystrybucji klucza szyfrującego za pomocą komunikacji EAPOL
• RFC 3580: IEEE 802.1x RADIUS Usage Guidelines– rola atrybutów dot. uwierzytelniania i rozliczania
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK26
EAP Extensible
AuthenticationProtocol
• Mechanizm wspierający różne metody uwierzytelniania– rozwinięty w celu wsparcia PPP– obecnie często używany w ramach IEEE 802– wykorzystywany przez standard IEEE 802.1x– RFC 3748 (następca RFC 2284)
• Implementowany bezpośrednio nad warstwą łącza danych, nie wymaga adresacji IP
• Elastyczność – autentykator nie musi wspierać metod uwierzytelniania, są one implementowane na serwerze EAP
• EAP nie ma możliwości fragmentacji i łączenia pakietów– implementacja w specyficznych metodach, np. EAP-TLS
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK27
EAP - pakiety
• 4 typy pakietów– zlecenie (request)– odpowiedź (response)– sukces (success)– porażka (failure)
• Format pakietu:Kod 1B
Identyfikator 1B
Rozmiar pakietu 2B
Typ 1B
Dane dane...
tylko w zleceniu i odpowiedzi
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK28
EAP - metody
• Pole typ wskazuje typ transmitowanych danych, jest równoważne z metodą EAP
• Standardowe metody EAP: MD5-Challenge, OTP, GTC– metody realizujące wymianę danych w celu
uwierzytelnienia– nie zalecane w sieciach bezprzewodowych jako
niewystarczająco bezpieczne
• Trzy dodatkowe („specjalne”) metody EAP:– Identity – podaj / przekaż nazwę użytkownika– Nak – brak zgody na proponowaną metodę
uwierzytelniania– Notification – rzadko używany, informacja dla
użytkownika
• Typy rozszerzone (expanded types) – w polu danych Vendor-ID, Vendor-Type, dane
• Typy eksperymentalne
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK29
EAP a RADIUS
• RFC 3579 – RADIUS & EAP• NAS przekazuje pakiety EAP z / do serwera RADIUS
– pakiety są opakowane w atrybucie EAP-Message• NAS może wspierać dowolną metodę EAP• NAS i suplikant negocjują stosowany typ EAP• NAS wysyła do suplikanta inicjujące zlecenie EAP-
Request/Identity• Suplikant wysyła EAP-Response/Identity• NAS (jeśli działa jako pass-through) umieszcza EAP-
Response/Identity w pakiecie Access-Request, w atrybucie EAP-Message
• Serwer RADIUS po odebraniu pakietu z atrybutem EAP-Message wysyła pakiet Access-Challenge z atrybutem EAP-Message
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK30
EAP a RADIUS
• Suplikant po odbiorze pakietu Access-Challenge odpowiada pakietem EAP-Response (umieszczonym w EAP-Message)
• Atrybut Message-Authenticator– służy do podpisywania pakietów zleceń, w celu nie
dopuszczenia do podszycia się pod nadawcę– wymagany w pakietach zawierających EAP-Message– wartość pola tworzona za pomocą algorytmu HMAC-
MD5 przy użyciu klucza tajnego i napisu będącego pakietem zlecenia
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK31
EAPOL EAP over LAN
• Sposób przenoszenia pakietów EAP między suplikantem a NAS w środowisku LAN– obecnie zdefiniowano dla 802.3/Ethernet MAC i Token
Ring/FDDI
• Ramka EAPOL– typ Ethernetu 2B– wersja protokołu 1B (wartość 1)– typ pakietu 1B:
EAP-Packet (000), EAPOL-Start (001), EAPOL-Logoff (010), EAPOL-Key (011), EAPOL-Encapsulated-ASF-Alert (100)
– rozmiar ciała pakietu 2B– ciało pakietu nB (wartość EAP-Packet, EAPOL-Key, EAPOL-
Encapsulated-ASF-Alert
• Ramki powinny być nieznakowane (untagged), opcjonalnie znakowane wg priorytetu
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK32
EAPOL EAP over LAN
• Ciało pakietu– w przypadku typu pakietu EAP-Packet zawiera
dokładnie jeden pakiet EAP• postać pakietu: kod (1B), identyfikator (1B), rozmiar (2B),
dane• kody: 1 – request, 2 – response, 3 – success, 4 - failure
– w przypadku typu pakietu EAPOL-Key zawiera dokładnie jeden deskryptor klucza
• postać deskryptora: typ deskryptora (1B), rozmiar klucza (2B), licznik powtórzeń (8B), klucz IV – Initialization Vector (16B), indeks klucza (1B), podpis cyfrowy klucza (16B), klucz (rozmiar ciała pakietu – 44)
• deskryptor RC4
– w przypadku typu pakietu EAPOL-Enacapsulated-ASF-Alert zawiera jedną ramkę alertu ASF
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK33
EAPOL - RADIUS
wg strony http://manageengine.adventnet.com/products/wifi-manager/eapol-logoff-attack.html
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK34
EAP – metody bezpieczne
• Rodzina metod opartych na certyfikatach: EAP-TLS, EAP-TTLS, PEAP
• EAP-TLS– zatwierdzony przez IETF, RFC 2716– typ oparty na protokole TLS, tj. na kryptografii klucza
publicznego– klient i serwer muszą dysponować certyfikatami,
weryfikacja autentyczności poprzez udowodnienie posiadania odpowiednich kluczy (przez obie strony!)
– TLS wspomaga generowanie kluczy używanych do przygotowania materiału kryptograficznego
– własność fast reconnect (w ramach protokołu TLS)
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK35
EAP-TLS
© 2002,Cisco Systems, Inc. All rights reserved.
RADIUSserverAP
[EAP-Type=EAP-TLS,Start bit set, no data]EAP-TLS Start
[EAP-Type=EAP-TLS
(TLS client_hello)] EAP-Response
EAP-Request
[EAP-Type=EAP-TLS(TLS server_hello ,TLS certificate, TLSserver_key_exchange,TLS certificate_request ,TLS server_hello_done)]
[EAP-Type=EAP-TLS(TLS certificate,
TLS client_key_exchange ,TLS certificate_verify,
TLS change_cipher_spec,TLS finished)]
EAP-Response
[EAP-Type=EAP-TLS(TLSchange_cipher_spec,TL
S finished)]
EAP-Request
[EAP-Type=EAP-TLS] EAP-Response
EAP-Success
Supplicant
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK36
EAP – metody bezpieczne
• EAP-TTLS– wprowadzony przez Funk Software i Certicom, kandydat na
standard IETF (brak RFC)– korzysta z protokołu TLS do stworzenia bezpiecznego
kanału transmisji dla przesyłania w nim innego protokołu uwierzytelniania
– wymagany tylko certyfikat serwera, klient nie musi dysponować certyfikatem
– w tunelu TLS są przekazywane pary atrybut,wartość – wsparcie dla różnych metod, również PAP (Password
Authentication Protocol), CHAP, MS-CHAP, MS-CHAPv2– umożliwia wykorzystanie popularnego stylu
uwierzytelniania opartego na haśle przy jednoczesnym bezpieczeństwie (odporność na podsłuch, atak man-in-middle)
– łatwa rozszerzalność
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK37
EAP – metody bezpieczne
• PEAP– protokół rozwijany wspólnie przez Microsoft, RSA
Security i CISCO– korzysta z protokołu TLS do stworzenia bezpiecznego
kanału transmisji dla przesyłania w nim protokołu uwierzytelniania
– wymagany tylko certyfikat serwera, klient nie musi dysponować certyfikatem
– warstwa TLS posadowiona nad EAP służy do realizacji wymiany zgodnej z protokołem EAP (w EAP-TTLS dopuszcza się metody nie-EAP)
• w tunelu TLS są wymieniane pakiety EAP
– nie definiuje metody uwierzytelniania, daje dodatkowe zabezpieczenia dla innych protokołów EAP
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK38
PEAP, EAP-TTLS, EAP-TLS
PEAP EAP-TTLS
EAP-TLS
uwierzytelnienie serwera
certyfikat certyfikat certyfikat
uwierzytelnienie klienta
dowolna metoda EAP
dowolna metoda uwierzyt.
certyfikat
ochrona danych użytkownika
tak, TLS tak, TLS nie
negocjacja szyfrowania sesji
nie tak nie
odporność na ataki
tak tak tak
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK39
EAP a 802.1x
wg strony https://www.surfnet.nl/innovatie/wlan/
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK40
Bezpieczne sieci bezprzewodowe a
RADIUS• Wspólny klucz tajny – shared secret
– ustalany między NAS (AP) a serwerem– w przypadku serwerów proxy – ustalany dla komunikacji
między serwerami– powinien być unikatowy, nietrywialny, min. 16 znaków,
słowo spoza słownika– “zakodowanie” hasła:
MD5( 128 bitowa liczba losowa + shared secret ) xor password
– hasła użytkowników mogą być proste do złamania, znajomość hasła pozwala na wykonanie ataku słownikowego na klucz tajny
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK41
Bezpieczne sieci bezprzewodowe a
RADIUS• Pole 'authenticator'
– 16B – w zleceniu (request authenticator): trudna do
przewidzenia liczba losowa– wartość przenoszona jako hasło
MD5( request authenticator + shared secret ) xor password
– w odpowiedzi pole response authenticator zawieraMD5( pakiet RADIUS zlecenia do pola request authenticator
włącznie + atrybuty odpowiedzi + shared secret )
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK42
Bezpieczne sieci bezprzewodowe a
RADIUS
• Dystrybucja dynamicznych kluczy tymczasowych– wygenerowanie materiału kryptograficznego dla dalszej
komunikacji– dynamiczna zmiana kluczy szyfrujących
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK43
Zarządzanie kluczami
• Metoda EAP po skutecznym uwierzytelnieniu generuje klucz szyfrujący (encryption key) zwany Master Session Key (MSK)– klucz składa się z dwóch części, po 64 bity: jedna (0-31)
dotyczy komunikacji suplikant – NAT, jest przesyłana w odpowiedzi RADIUS jako atrybut MS-MPPE-Recv-Key, druga dotyczy komunikacji NAT-Supplicant i jest przesyłana w atrybucie MS-MPPE-Send-Key
– wg dok. Internet-Draft draft-ietf-eap-keying-09 powinny być tworzone również:
• klucz EMSK (Extended MSK) – Authentication Key• klucz IV (Initialisation Vector)
– w TLS-ie klucze powstają na bazie TLS master secret
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK44
Zarządzanie kluczami
• Z klucza MSK jest tworzony po stronie serwera i suplikanta klucz Pairwise Master Key (PMK)
• Suplikant i AP w ramach protokołu EAPOL (EAPOL-Key) realizują w oparciu o klucz PMK tzw. 4-way handshake, jest uzgodniany PTK (Pairwise Transient Key), będący zbiorem kluczy:– Key Confirmation Key KCK (dowód posiadania PMK) – Key Encription Key KEK służy do dystrybucji Group
Transient Key (GTK)– Temporal Key 1 & 2 (TK1/TK2) służy do szyfrowania
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK45
Zarządzanie kluczami
• Suplikant i AP w ramach protokołu EAPOL realizują w oparciu o klucz KEK tzw. handshake klucza grupowego, następstwem jest uzgodnienie GTK (Group Transient Key), AP przesyła ten klucz do suplikanta, klucz jest stosowany do bezpiecznej transmisji pakietów broadcast i multicast
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK46
Uwierzytelnianiei autoryzacja
• Uwierzytelnienie dotyczy użytkownika, nie urządzenia
• Bezpieczeństwo chronionych danych uwierzytelniania
• Centralizacja punktu uwierzytelniania, integracja z innymi usługami sieciowymi
• Możliwość szybkiego ponownego uwierzytelnienia (fast reauthentication) – bez uczestnictwa zdalnego serwera
• Możliwość dodatkowej kontroli uprawnień użytkownika – przynależność do określonej grupy– zgoda na dostęp dial-up– lokalna polityka: typ tunelowania, limity dot. sesji
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK47
Diameter
• RFC 3588• Oficjalna strona projektu: www.diameter.org• Protokół typu AAA, przeznaczony dla aplikacji
kontrolujących dostęp do sieci, albo dających usługi mobilne
• Nazwa – gra słów, RADIUS to poprzednik, Diameter to 2xRADIUS, promień (radius) – średnica (diameter)
• Diameter jest kompatybilny wstecz• Diameter jest udoskonaleniem RADIUS-a
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK48
Diameter - własności
• Bazuje na TCP lub SCTP• Używa bezpiecznych warstw transportowych IPSec
lub TLS• Wspiera obsługę zmian stanów• Dysponuje większą przestrzenią adresową na
obszar atrybut-wartość oraz na identyfikatory (4B nie 1B)
• Protokół typu peer-to-peer nie klient-serwer• Może dynamicznie lokalizować partnera w oparciu
o DNS SRV (RFC 2782) i NAPTR (RFC 3403)
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK49
Diameter - własności
• Możliwość negocjacji• Potwierdzenia na poziomie aplikacji, metody
regeneracji, zgodnie z RFC 3539, AAA transport Profile
• Powiadamianie o błędach• Lepsze wsparcie roamingu• Lepsza rozszerzalność, możliwość definiowania
nowych poleceń, atrybutów• Wbudowane wsparcie obsługi sesji użytkownika i
działań rozliczeniowych
Seminarium eduroam – UMK, 16-17.03.2006 Maja Górecka-Wolniewicz UCI UMK50
Diameter – implementacje
• Projekt typu “open source”http://www.opendiameter.org– GNU public license– w bieżącej wersji 1.0.7g API– serwer i klient planowany w wersji 1.0.8