Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Seminarium eduroam – UMK, 16-17.03.2006 Tomasz Wolniewicz UCI UMK Maja Górecka-Wolniewicz UCI UMK Protokół RADIUS i jego zastosowania.

Podobne prezentacje


Prezentacja na temat: "Seminarium eduroam – UMK, 16-17.03.2006 Tomasz Wolniewicz UCI UMK Maja Górecka-Wolniewicz UCI UMK Protokół RADIUS i jego zastosowania."— Zapis prezentacji:

1 Seminarium eduroam – UMK, Tomasz Wolniewicz UCI UMK Maja Górecka-Wolniewicz UCI UMK Protokół RADIUS i jego zastosowania

2 Seminarium eduroam – UMK, 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

3 Seminarium eduroam – UMK, 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ść

4 Seminarium eduroam – UMK, 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

5 Seminarium eduroam – UMK, Maja Górecka-Wolniewicz UCI UMK5 RADIUS implementacja 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)

6 Seminarium eduroam – UMK, Maja Górecka-Wolniewicz UCI UMK6 Pakiety RADIUS Struktura pakietu Kod 1B Identyfikator 1B Rozmiarpakietu 2B Autentykator łącznie16B AtrybutyłącznienB

7 Seminarium eduroam – UMK, 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

8 Seminarium eduroam – UMK, 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

9 Seminarium eduroam – UMK, 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

10 Seminarium eduroam – UMK, 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

11 Seminarium eduroam – UMK, 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

12 Seminarium eduroam – UMK, 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 1B Wartość 0-nB atrybuty mają przypisane ident. numeryczne liczony łącznie z polem typu i rozmiaru 5 typów: tekst UTF-8, napis, adres, liczba, czas

13 Seminarium eduroam – UMK, 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 StateWysyłany przez serwer do klienta w Access-Challenge, musi zostać przesłany niezmieniony przez klienta do serwera w Access-Request 25 ClassWysył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 przeznaczono na atrybuty accountingowe

14 Seminarium eduroam – UMK, 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ść

15 Seminarium eduroam – UMK, 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

16 Seminarium eduroam – UMK, 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

17 Seminarium eduroam – UMK, 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

18 Seminarium eduroam – UMK, Maja Górecka-Wolniewicz UCI UMK18 Accounting - informacje rozliczeniowe 40 Acct- Status-Typepoczątek/koniec sesji (start/stop / interim-update accounting-on/off) 41 Acct-Delay-Timeile sekund klient próbował przesłać rekord 42 Acct-Input-Octets 43 Acct-Output-Octets 44 Acct-Session-Idunikatowy identyfikator sesji 45 Acct-Authenticsposó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

19 Seminarium eduroam – UMK, 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ć

20 Seminarium eduroam – UMK, 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

21 Seminarium eduroam – UMK, 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 atrybuc i e User-Password Zleceniu Access-Challenge może towarzyszyć atrybut State, który MUSI być transmitowany przezroczyście

22 Seminarium eduroam – UMK, 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

23 Seminarium eduroam – UMK, 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)

24 Seminarium eduroam – UMK, 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.

25 Seminarium eduroam – UMK, Maja Górecka-Wolniewicz UCI UMK x w sieci bezprzewodowej Pojęcie portów logicznych –wykorzystani e 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

26 Seminarium eduroam – UMK, Maja Górecka-Wolniewicz UCI UMK26 EAP Extensible Authentication Protocol 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 imp l ementowane na serwerze EAP EAP nie ma możliwości fragmentacji i łączenia pakietów –implementacja w specyficznych metodach, np. EAP-TLS

27 Seminarium eduroam – UMK, 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 Rozmiarpakietu 2B Typ 1B Dane dane... tylko w zleceniu i odpowiedzi

28 Seminarium eduroam – UMK, 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

29 Seminarium eduroam – UMK, 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

30 Seminarium eduroam – UMK, 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

31 Seminarium eduroam – UMK, 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

32 Seminarium eduroam – UMK, 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

33 Seminarium eduroam – UMK, Maja Górecka-Wolniewicz UCI UMK33 EAPOL - RADIUS wg strony

34 Seminarium eduroam – UMK, 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)

35 Seminarium eduroam – UMK, Maja Górecka-Wolniewicz UCI UMK35 EAP-TLS

36 Seminarium eduroam – UMK, 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ść

37 Seminarium eduroam – UMK, 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

38 Seminarium eduroam – UMK, Maja Górecka-Wolniewicz UCI UMK38 PEAP, EAP-TTLS, EAP-TLS PEAPEAP-TTLSEAP-TLS uwierzytelnienie serwera certyfikat uwierzytelnienie klienta dowolna metoda EAP dowolna metoda uwierzyt. certyfikat ochrona danych użytkownika tak, TLS nie negocjacja szyfrowania sesji nietaknie odporność na atakitak

39 Seminarium eduroam – UMK, Maja Górecka-Wolniewicz UCI UMK39 EAP a 802.1x wg strony https://www.surfnet.nl/innovatie/wlan/

40 Seminarium eduroam – UMK, 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

41 Seminarium eduroam – UMK, 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 zawiera MD5( pakiet RADIUS zlecenia do pola request authenticator włącznie + atrybuty odpowiedzi + shared secret )

42 Seminarium eduroam – UMK, 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

43 Seminarium eduroam – UMK, 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

44 Seminarium eduroam – UMK, 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

45 Seminarium eduroam – UMK, 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

46 Seminarium eduroam – UMK, Maja Górecka-Wolniewicz UCI UMK46 Uwierzytelnianie i 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

47 Seminarium eduroam – UMK, Maja Górecka-Wolniewicz UCI UMK47 Diameter RFC 3588 Oficjalna strona projektu: 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

48 Seminarium eduroam – UMK, 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)

49 Seminarium eduroam – UMK, 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

50 Seminarium eduroam – UMK, Maja Górecka-Wolniewicz UCI UMK50 Diameter – implementacje Projekt typu open source –GNU public license –w bieżącej wersji 1.0.7g API –serwer i klient planowany w wersji 1.0.8


Pobierz ppt "Seminarium eduroam – UMK, 16-17.03.2006 Tomasz Wolniewicz UCI UMK Maja Górecka-Wolniewicz UCI UMK Protokół RADIUS i jego zastosowania."

Podobne prezentacje


Reklamy Google