Univerzitet u Tuzli

Fakultet elektrotehnike
Komunikacije

























SEMINARSKI RAD
IZ TELEKOMUNIKACIONIH MREA

Autentifikacijski protokoli (RADIUS server)
























Student:
Hasanovi Denad Decembar 2013
Sadraj:
1. RADIUS protokol ........................................................................................................3.
1.1. Uvod ......................................................................................................................... 3.
1.2. O RADIUS protokolu .............................................................................................. 3.
1.3. Upit klijenta .............................................................................................................. 4.
1.4. Odgovor servera ....................................................................................................... 5.
1.5. Procesiranje odgovora servera ................................................................................. 5.
1.6. Problemi sa RADIUS protokolom ........................................................................... 6.
1.6.1. Napad na tajni klju pomou Response Authenticator polja ........................ 6.
1.7. Enkripcija User-Password atributa ........................................................................... 6.
1.8. Napad na tajni kljuc pomou User-Password atributa ............................................. 7.
1.9. Napad na korisniku ifru pomou User-Password atributa .................................... 7.
1.10. Napadi bazirani na Response Authennticator atributu ......................................... 7.
1.10.1. Pasivni napad pomou Request Authenticators atributa ............................... 8.
1.10.2. Aktivni napad pomou Request Authenticators atributa .............................. 8.
1.10.3. Krivotvorenje odgovora temelju Request Authenticator atributa ............... 8.
1.10.4. Provoenje DoS-a predvianjem vrijednosti Request Authenticator atributa 8.
1.11. Napomene vezane za tajni klju ........................................................................... 9.

2. Primjer......................................................................................................................10.
3.Literatura....................................................................................................................12.


















1. RADIUS protokol
1.1. Uvod

RADIUS je danas vrlo esto koriten protokol za autentikaciju, autorizaciju te administraciju
korisnika, ija je primjena najrairenija upravo kod ugraenih mrenih ureaja poput usmjerivaa,
preklopnika, modema, te brojnih drugih njima slinih ureaja. Protokol se bazira na klijent-server
modelu (engl. client-server), koji kao transportno sredstvo koristi UDP mreni protokol. Na strani
klijenta koristi se Network Access Server (NAS) programski paket, koji obavlja zadae vezane za
prosljeivanja korisnikih parametara RADIUS serveru, te obradu primljenih odgovora. S druge
strane, RADIUS serveri zadueni su za prihvatanje upita, provjeru primljenih korisnikih parametara,
te vraanja potrebnih konfiguracijskih parametara, koji e klijentu omoguiti pruanje adekvatne
usluge korisniku. RADIUS serveri se takoer mogu koristiti i kao proxy klijenti drugim RADIUS
serverima, ili nekim drugim sistemima za autentikaciju korisnika.
Sama komunikacija izmeu klijenta i servera bazira se na tajnom kljuu kojeg dijele klijent i server, i
koji se kao takav iz sigurnosnih razloga nikada ne alje raunarskom mreom.
RADIUS protokol koristi se iz vie razloga :
mreni ureaji poput gore navedenih u osnovi ne posjeduju mogunost pohranjivanja velikog
broja autentikacijskih parametara razliitih korisnika, s obzirom na ograniene resurse s
kojima raspolau.
RADIUS protokol olakava i centralizira administraciju korisnika, to moe biti vrlo vaan, te
presudan faktor u okolinama gdje postoji potreba za administracijom velikog broja korisnika.
Kao primjer mogu se uzeti vei ISP (Internet Service Provideri) provajderi usluga, kod kojih
se svakodnevno javlja potreba za dodavanjem novih, brisanjem starih, te modificiranjem
postojeih korisnikih rauna. U takovim okolinama alati za centraliziranu i jednostavniju
administraciju poput RADIUS protokola mogu imati presudni znaaj na njihovo poslovanje.
RADIUS protokol prua odreeni nivo zatite protiv aktivnih napada neovlatenih korisnika.
Za razliku od veine drugih protokola ovog tipa koji nude ili nedovoljnu, ili povremenu ili
ope ne pruaju nikakvu zatitu, RADIUS u tu svrhu koristi TACACS+ i LDAP protokole za
autentikaciju.
Velika podrka razliitih proizvoaa mrene opreme. Budui da se RADIUS protokol
implementira najee u sklopu ugraenih mrenih ureaja, u takovim okolinama postoji mala
ili gotovo nikakva mogunost nadogradnje drugih protokola. Zbog rairenosti ovog protokola
svaka promjena koja bi se nainila u smjeru njegovog poboljanja morala bi biti kompatibilna
s postojeim rjeenjima.
Upravo se iz navedenih razloga RADIUS protokol u dananje vrijeme smatra de facto standardom
za udaljenu autentikaciju korisnika, te se kao takav implementira i kod novijih i kod starijih mrenih
ureaja.

1.2. O RADIUS protokolu

Podaci izmeu klijenta i servera se razmjenjuju putem RADIUS data paketa, enkapsuliranih unutar
UDP paketa protokola nieg nivoa. RADIUS komunikacija koristi upit-odgovor (engl. challenge-
response) paradigmu, u kojoj klijent alje upite serveru, a server na temelju njih vraa odgovor
klijentu.
Format jednog RADIUS paketa je sljedei:

















3

Znaenje pojedinih polja:
Code jedan bajt veliko polje, koje definira tip RADIUS data paketa. Mogue vrijednosti
ovog polja prikazane su u sljedeoj tablici:

O 1 Access-Request
O 2 Access-Accept
O 3 Access-Reject
O 4 Accounting-Request
O 5 Accounting-Response
O 11 Access-Challenge
O 12 Status-Server (experimental)
O 13 Status-Client (experimental)
O 255 Reserved
Identifier (ID)- jedan bajt veliko polje, koje klijentu omoguuje jednoznanu identifikaciju
parova upit-odgovor.
Length 2 bajta koja predstavljaju veliinu paketa.
Authenticator vrijednost koja se koristi za provjeru ispravnosti odgovora od strane RADIUS
servera, a ujedno se koristi kao dio algoritma za prikrivanje, odnosno zatitu korisnike ifre.
Attributes sekcija u kojoj se nalaze proizvoljni atributi koji pripadaju samoj sesiji (upitu ili
odgovoru). Jedini atributu koji su obavezni su User-Name i User-Password atributi, a ostali su
proizvoljni.

U nastavku e biti iznesen jedan tipini postupak RADIUS autentikacije, u kojemu RADIUS klijent na
temelju korisnikog zahtjeva serveru alje Access-Request upit sa navedenim korisnikim
imenom i ifrom, na to server odgovara sa Access-Accept, Access-Reject odgovorom ili odbijanjem
sesije. U ovakvom pristupu klijent je taj koji eli svoje autentikacijske parametre (korisniko ime i
ifru) provjeriti kod servera, dok je server onaj koji ima pravo pristupa sistemu baze podataka, sa
arhivom korisnikih parametara autentikacije. Na temelju postavljenog upita RADIUS klijenta, server
onda moe obraditi korisniki zahtjev, te ovisno o regularnosti primljenih parametara dozvoliti ili
zabraniti pristup resursima.

1.3. Upit klijenta

Klijent zapoinje sesiju kreiranjem RADIUS upita sa postavljenim Access-Request kodom, koji mora
minimalno sadravati User-Name i User-Password korisnike atribute. Bajt identifikacije (ID) tog
paketa odabire se proizvoljno od strane klijenta i kao takav nije definiran RADIUS protokolom.
Generiranje ovog broja najee je implementirano u obliku jednostavnog brojaa koji se uveava za
jedan generiranjem svakog novog upita. Paket takoer sadri Request Authenticator vrijednost unutar
Autenthicator polja RADIUS paketa. Ova vrijednost takoer predstavlja sluajno odabrani 16 bajtni
znakovni niz, a algoritam njegovog generisanja kako emo kasnije vidjeti, ima presudan znaaj
za sigurnost ovog protokola. RADIUS paket sam po sebi nije zatien ni na koji nain, izuzev
User-Password atributa koji se iz sigurnosnih razloga zatituje enkripcijom na nain opisan u
nastavku teksta.






4

U ovakvom pristupu klijent i server meusobno dijele neku vrstu tajnog kljua (engl. secret), koji
predstavlja podlogu za postupak kriptiranja korisnike korisnike ifre. Postupak zatite korisnike
ifre je sljedei:

Request Authenticator vrijednost (RA) se spaja sa spomenutim tajnim kljuem (S)
kojeg dijele klijent i server.

tako dobiveni niz obrauje se MD5 hash funkcijom, to e rezultirati 16 bajtnim
znakovnim nizom

slijedi primjena XOR funkcije izmeu dobijenog 16 bajtnog niza i korisnike korisnike ifre, kako bi
se na taj nain dolo do zatiene korisnike ifre. Ukoliko je korisnika ifra dua od 16 bajtova,
provode se dodatne MD5 kalkulacije, kako bi se dolo do eljenog rezultata.

Formalnije:
Oznaimo tajni klju klijenta i servera sa S, te pseudo sluajnu 128 bitnu vrijednost Request
Authenticator sa RA. Korisnika ifra dijeli se na 16 bajtne blokove p1,,pn, gdje e vrijednost
zadnjeg bloka biti nadopunjena nulama, kako bi se dobilo tano 16 blokova veliine jednog bajta.
Opisanim matematikim operacijama (izraz 1) dobivaju se c1,, cn blokovi, ijim se kombiniranjem
dobiva konani rezultat.

c1 = p1 XOR MD5 (S + RA)
c2 = p2 XOR MD5 (S + c1)
.
. (1)
.
cn = pn XOR MD5 (S+cn-1)
Zatieni User-Password atribut dobit e se spajanjem dobivenih c1,,cn blokova (izraz 2).

User-Password = c1 + c2 + +cn (2)

,gdje operator + predstavlja operaciju spajanja znakovnih nizova.

1.4. Odgovor servera

Nakon primljenog RADIUS Access-Request upita, server prvo provjerava da li za tog klijenta postoji
tajni klju koji oni meusobno dijele. Ukoliko server ne posjeduje tajni klju tog klijenta, zahtjev se
odbija. Ukoliko takav klju postoji, server prolazi kroz neto izmijenjeni postupak kriptiranja, kako bi
doao do originalne nezatiene korisnike ifre. Nakon toga slijedi postupak provjere ispravnosti
dobijene korisnike ifre, koji e ukoliko je regularan rezultirati vraanjem Access-Accept paketa
klijentu. Ukoliko je proslijeena ifra neispravna (ne odgovara paru Username/Password koji server
posjeduje u svojoj bazi podataka) klijentu se vraa Access-Reject paket, kojim se odbija nastavak
procesa autentikacije. U oba sluaja Access-Accept i Access-Reject vraeni paketi sadre identinu
vrijednost bajta identifikacije (ID), kao to je sadravao i originalni Access-Request upit klijenta.
Vrijednost Response Authenticator atributa vraenog paketa dobiva se primjenom MD5 hash funkcije
na parametre istog paketa u kombinaciji sa vrijednou polja Response Authenticator originalnog
upita klijenta (izraz 3). MatematiLki formulirano:

RA = MD5(Code+ID+Length+RequestAuth+Attributes+S) (3)

gdje + operator oznacava operaciju spajanja.

1.5. Procesiranje odgovora servera

Nakon primljenog odgovora od strane RADIUS servera, klijent na temelju bajta identifikacije
pokuava odrediti da li se odgovor zaista odnosi na njegov upit. Usporeivanjem vrijednosti ID polja
poslanog (Access-Accept) i primljenog (Access-Accept ili Access-Reject) paketa klijent vrlo
jednostavno moe identificirati regularnost odgovora, odnosnu njegovu pripadnost upitu klijenta.
Ukoliko se ove dvije vrijednosti ne slau, klijent odgovor smatra neregularnim i sesija se prekida.




5
Slijedi provjera Response Authenticator polja primljenog paketa provoenjem iste matematike obrade
kao i na strani servera, kako bi se potvrdilo da odgovor zaista stie od strane servera. Ukoliko se
rezultati ne poklapaju, odgovor se smatra neregularnim i sesija se prekida. Ukoliko je klijentu vraen
Access-Accept RADIUS paket sa valjanim sadrajem, korisniko ime i ifra smatraju se regularnima,
to e rezultirati uspjenom autentikacijom korisnika. Ukoliko je klijentu vraen Access-Reject
RADIUS paket sa valjanim sadrajem, korisniko ime i ifra smatraju se neregularnim, to e
rezultirati neuspjenom autentikacijom korisnika.
1.6. Problemi sa RADIUS protokolom

RADIUS protokol sadri niz sigurnosnih propusta, koji su posljedica ili propusta u implementaciji
samog protokola ili neispravne, odnosno nepotpune implementacije programske podrke. U nastavku
ovog dokumenta biti e opisani neki od sigurnosnih propusta vezanih za RADIUS protokol.

1.6.1. Napad na tajni klju pomou Response Authenticator polja

Podloga za provoenje ovog tipa napada na RADIUS protokol, je upravo priroda samog naina na koji
se generira vrijednost Response Authenticator polja, kod Access-Accept ili Access-Reject RADIUS
paketa. Naime, pregledavanjem upravo navedenih RADIUS paketa, te koritenjem snanih algoritama
za razbijanje, postoje realne mogunosti za probijanje vrijednosti tajnog kljua. Ukoliko se pomnije
promotre argumenti MD5 hash algoritma, koje server koristi za generiranje odgovora klijentu (izraz
3), moe se primijetiti da je jedina nepoznata u tom izrazu upravo tajni klju koji dijele klijent i server.
Na temelju detektiranih RADIUS paketa, napadau se postavlja ovakav problem:

RA = MD5(Code+ID+Length+RequestAuth+Attributes+X) (4)

, gdje X predstavlja tajni klju koji se eli odgonetnuti.

Na temelju poznatih argumenata napada u svakom trenutku moe izraunati slijedei izraz:

RA = MD5(Code+ID+Length+RequestAuth+Attributes) (5)

Sada se metodom pokuaja i pogreke, te snanim raunarskih algoritmima moe s vrlo
velikom vjerovatnoom odgonetnuti tajni klju, klijenta i servera.

1.7.Enkripcija User-Password atributa

Algoritam koji se u sluaju RADIUS protokola koristi za ekripciju korisnike korisnike ifre,
odnosno User-Password atributa, spada u grupu stream chiper algoritama za enkripciju podataka, gdje
se MD5 hash funkcija koristi kao generator pseudo sluajnih brojeva (PRNG). Upravo sigurnost
ovakvog postupka zatite povjerljivih podataka (u ovom sluaju korisnike ifre) ovisi o snazi i
kvaliteti, u ovom sluaju odabrane MD5 hash funkcije, odnosno o kvaliteti odabira tajnog kljua kojeg
dijele klijent i server. to su ovi elementi kvalitetnije odabrani, sigurnost cijelog postupka biti e na
vioj razini. No, budui da MD5 hash funkcija u svojoj osnovi nije predviena da se koristi kao
primitiva stream chiper grupe algoritma, ve kao isti alat za enkripciju podataka, ona se u sluaju
RADIUS protokola smatra neprikladno odabranim alatom. Kako e se vidjeti u nastavku teksta,
upravo e spomenuto neadekvatno koritenje MD5 hash primitive u sluaju RADIUS protokola, biti
uzrok odreenog broja sigurnosnih propusta, koje neovlateni korisnik moe iskoristiti za
neautoritizovani pristup povjerljivim korisnikim podacima.












6
1.8. Napad na tajni klju pomou User-Password atributa

Kao posljedica koritenja stream chiper algoritma za kriptiranje korisnike ifre prilikom slanja upita
serveru, napadau se i u ovom sluaju prua mogunost odgonetanja tajnog kljua kojeg dijele klijent i
server. Napad poinje pokuajem autentikacije napadaa kod RADIUS klijenta, sa njemu poznatom, i
u tu svrhu osmiljenom korisnikom ifrom. Na temelju tako primljenog zahtjeva RADIUS klijent
formirat e Access-Request upit, koji e se proslijediti serveru u svrhu provjere korisnikih podataka.
User-Passsword atribut tog paketa, biti e dobiven na nain kako je to opisano, sa naglaskom na
injenicu da je kao argument enkripcije koritena napadau poznata ifra. Ukoliko sada isti napada
analizom mrenog prometa uhvati generirani RADIUS Access-Request upit, te primjeni XOR
operaciju na zatieni User-Password atribut, kao rezultat dobit e izlaznu vrijednost slijedee
matematike operacije:

MD5(Shared Secret + Request Authenticator) (6)

S obzirom da je vrijednost Request Authenticator polja poznata, i da se ista moe nai unutar Access-
Request paketa, ostaje samo jedna nepoznata, i to upravo tajni klju koji se eli odgonetnuti.
Metodom pokuaja i pogreke te uporabom snanih raunarskih algoritama, i na ovaj nain je mogue
doi do povjerljivog tajnog kljua klijenta.

1.9. Napad na korisniku ifru pomou User-Password atributa

Drugi sigurnosni propust koji je takoer posljedica neprikladne upotrebe stream chiper algoritma za
kriptiranje korisnike korisnike ifre, neovlatenom korisniku omoguuje uspjeno nagaanje
korisnike ifre, a samim time i uspjenu autentikaciju kod servera. Osnovni preduvjet za provoenje
ove vrste napada je taj da server ne posjeduje ogranienje na maksimalni broj neuspjelih pokuaja
autentikacije. Prvi dio napada isti je kao i u prethodnom sluaju. Napada klijentu upuuje zahtjev za
autentikacijom sa valjanim korisnikim imenom proizvoljnog korisnika, te sa nasumce predvienom
njegovom ifrom (najvjerovanije pogrenom). Nakon tog potrebno je na nain opisan u prethodnom
poglavlju, doi do izlazne vrijednosti matematike operacije

MD5(Shared Secret + Request Authenticator) (7)

Ukoliko se promotri izraz (1) moe se primijetiti da napada na temelju ovako izraunate vrijednosti,
moe u svakom trenutku generirati novi Access-Request paket sa istim korisnikim imenom i drugom,
novom, opet nasumce pretpostavljenom vrijednou korisnike ifre. Ukoliko server nema definirano
ogranienje na broj pokuaja prijavljivanja u sistem, napada slanjem velikog broja Access-Request
paketa sa nasumce odabranom vrijednou korisnike korisnike ifre, moe doi do ispravne
korisnike korisnike ifre.
1.10. Napadi bazirani na Response Authenticator atributu

Kompletna sigurnost RADIUS protokola u osnovi ovisi o kvaliteti algoritma za generiranje Request
Authenticator atributa. U svrhu uspjenog i sigurnog funkcioniranja RADIUS protokola spomenuti
atribut mora biti jedinstven i nepredvidljiv. Budui da sama specifikacija ovog protokola izriito ne
ukazuje na izuzetnu vanost postupka generisanja ovog atributa, odreeni broj implementacija koristi
loe i povrne implementacije mehanizma za generiranje sluajnih brojeva, koji se koristi u svrhu
generisanja vrijednosti ovog atributa. Naime, poznato je da kvaliteta i sigurnost gotovo kod svih
algoritama za kriptiranje ponajvie ovisi upravo o mehanizmu za generiranje sluajnih brojeva (engl.
pseudorandom number generator, ili PRNG). to vie taj mehanizam posjeduje deterministika
svojstva, to je algoritam enkripcije lake provaliti . Potpuno identina situacija je i sa RADIUS
protokolom.









7
1.10.1. Pasivni napad pomou Request Authenticators atributa

Pasivnim promatranjem mrenog prometa izmeu RADIUS klijenta i servera, napada s vremenom
moe kreirati neku vrstu RADIUS rjenika sa Request Authenticators atributima i njima
odgovarajuim zatienim User-Password atributima. Promatranjem vee koliine mrenog prometa,
napadau se otvara mogunost da iz kriptiranih korisnikih ifri eliminira utjecaj tajnog kljua, te da
na taj nain doe do originalne nezatiene korisnike korisnike ifre. Naime, primjenom XOR
logikog operatora nad zatienim korisnikim iframa, napada kao rezultat moe dobiti XOR
kombinaciju nezatienih ifri, to predstavlja prvi korak napada. Uspjenost ovog napada uveliko e
ovisiti o svojstvima korisnikih ifri. Ukoliko su one sve jednake duljine ovaj napad nee dati neto
znaajnije rezultate. No, budui da praksa pokazuje da su korisnike ifre u pravilu razliitih duina i
svojstava, ova vrsta napada e u veini sluajeva rezultirati veim ili manjim uspjehom. Idealna
situacija za uspjeno provoenje opisanog napada je kada su korisnike ifre krae od 16 bajtova, te
meusobno razliitih duina. Raznim statistikim metodama, te uzastopnim ponavljanjem pokuaja
napada neovlatenom korisniku se ovim putem otvara mogunost otkrivanja korisnike ifre korisnika.
1.10.2. Aktivni napad pomou Request Authenticators atributa

U ovom sluaju neovlateni korisnik zapoinje napad slanjem veeg broja RADIUS zahtjeva klijentu,
sa svojim proizvoljno odabranim korisnikim iframa, ime e se aktivirati slanje Access-Request
upita serveru. Nakon toga slijedi presretanje generiranih paketa prema serveru, te biljeenje Request
Authenticator i User-Password atributa unutar tih paketa. I u ovom sluaju potrebno je uoiti da se u
ovim paketima nalazi zatiena ifra, koja je poznata napadau, budui da je on inicirao sam upit.
Primjenom XOR logikog operatora izmeu poznatih nezatienih, te generiranih zatienih ifri,
napada vrlo jednostavno dolazi do MD5(Shared Secret + Request Authenticator) vrijednosti
generiranih Access-Request paketa. Na ovaj nain napadau se omoguuje kreiranje rjenika sa
parovima Request Authenticator atributa i njima pripadnih MD5(Shared Secret + Request
Authenticator) vrijednosti.
Ukoliko neovlateni korisnik sada detektira regularni Access-Request upit sa nekom od vrijednosti
Request Authenticator atributa koja je zabiljeena u prethodnoj fazi napada, i u ovom sluaju postoji
realna mogunost dolaska do korisnike korisnike ifre. Naime, primjenom XOR operacije izmeu
MD5(Shared Secret + Request Authenticator)vrijednosti koja prema kreiranom rjeniku odgovara
uoenom Request Authenticator atributu, i zatienog User-Password polja detektiranog paketa,
mogu je dolazak do valjane nezatiene korisnike ifre.
1.10.3. Krivotvorenje odgovora temelju Request Authenticator atributa

Neovlateni korisnik takoer moe praenjem i analizom mrenog prometa kreirati rjenik sa
odgovarajuim Request Authenticators, ID vrijednostima, te odgovarajuim odgovorima servera.
Ukoliko sada neovlateni korisnik iizmeu klijenta i servera detektira RADIUS paket sa vrijednostima
ID i Request Authenticators polja, koje se poklapaju sa nekom od vrijednosti zabiljeenih u prethodnoj
fazi napada (kreiranje odgovarajueg rjenika vrijednosti), napada se moe lano predstaviti klijentu
kao server, te vratiti odgovor koji prema stvorenom rjeniku pripada detektiranom paru vrijednosti. Na
ovaj nain napadau se omoguuje regularna autentikacija kod RADIUS servera, bez poznavanja
valjane korisnike korisnike ifre.

1.10.4. Provoenje DoS-a predvianjem vrijednosti Request Authenticator atributa

Podloga za provoenje napada uskraivanjem raunarskih resursa u ovom sluaju upravo je eventualna
predikcija generiranih vrijednosti Request Authenticator atributa. Naime, napada privremeno moe
preuzeti ulogu RADIUS klijenta, te na temelju predvienih vrijednosti Request Authenticator i ID
polja zapoeti slanje regularnih Access- Request upita. Zbog nepoznavanja ostalih parametara Access-
Request paketa, (korisnikog imena i korisnike ifre) server e na ove upite odgovarati Access-Reject
paketima. I u ovoj situaciji e napada kreirati prikladni rjenik vrijednosti koji e povezivati
maliciozno generirane Access-Request upite, te njima odgovarajue Access-Reject odgovore. Na
temelju ovako kreiranog rjenika napada e u fazi provoenja stvarnog napada moi na regularne
valjane Access-Request upite klijenta odgovarati lanim (ali regularnim) Access-Request odgovorima
iz rjenika, to e onemoguiti autentiakciju korisnika sa valjanim korisnikim imenom i ifrom.



8


1.11. Napomene vezane za tajni klju

Specifikacija RADIOUS protokola dozvoljava koritenje istog tajnog kljua za vie korisnika
RADIOUS sistema. Iako to nije eksplicitno izneseno, takva praksa smatra se loim rjeenjem i
ne preporuluje se u ni u kojim sluajevima. Naime, takav pristup dodatno meusobno
povezuje sve korisnike, to napadau olakava provoenje svih gore opisanih napada na
RADIUS protokol, budui da smanjuje broj pokuaja potrebnih za uspjeno provoenje
napada. Dodatni problem je taj to veina implementacija RADIOUS klijenta i servera za tajni
klju dozvoljavaju koritenje samo ASCII znakovnih nizova, to unosi dodatni sigurnosni
rizik. Naime na taj nain mogue je koritenje samo 94 znaka iz skupa ASCII znakova(od njih
256), to napadau takoer bitno olakava zadatak.
Osim toga neke implementacije unose dodatno ograniLenje na tajni klju, time to
njegovu duljinu ograniavaju na svega 16 znakova ili manje.









































9
2. Primjer

Elektron
The Elektron RADIUS server from Periodik Labs is a Windows GUI-based server that's targeted
toward wireless authentication for small and midsize networks, but supports other AAA purposes as
well. It's offered as a 30-day free trial and then costs $750 for a single server license.
Elektron can run on Windows XP Pro, Vista, Windows 7 and Windows Server 2003 and 2008. There's
also a Mac OS X edition that runs on 10.5 or later or with an Intel Core Duo or better processor. Both
require at least 512MB of memory and 20MB of free disk space.
Elektron supports the following authentication methods: PEAP, TTLS, EAP-FAST, EAP-TLS, LEAP,
PAP, CHAP, MS-CHAP, MS-CHAPv2, EAP-MS-CHAPv2, EAP-MD5, EAP-GTC, and EAP-OTP. It
also supports the following databases for the user account data: Internal database (configurable via the
GUI called Elektron Accounts), Windows accounts, Mac OS X Directory Services, Active Directory
and other LDAP directories, SQL and other ODBC compliant data sources, Remote RADIUS servers
and Script.
We tested Elektron Version 2.2 in Windows Server 2008 R2 on a VMware virtual machine. The
installation was very simple and only took about a minute. It uses a typical Windows installer and
didn't prompt us for any server-related settings.
Immediately after the installation we found a Setup Wizard to help configure Elektron for wireless
authentication. It prompted us to create a password (shared secret) for a wireless access point
(RADIUS client) and helped configure/create a server certificate. The wizard was helpful, but could be
improved by allowing you to enter passwords for individual access points rather than creating a catch-
all entry for any access point, which is a less secure method.
After using the Setup Wizard we were left in the dark as to our next step. Since we're experienced with
the RADIUS process, we knew we had to configure the Authentication Provider (we used the internal
database) and input user account info (we created a user on the Elektron Accounts page). But those not
familiar with RADIUS might be confused because the wizard doesn't cover this and the Getting
Started section in the documentation skips it as well. Nevertheless, after configuring our wireless
access point with WPA2-Enterprise we were able to authenticate via Protected Extensible
Authentication Protocol (PEAP).
While reviewing the Authentication settings we found we could add multiple Authentication Providers
and dynamically assign users to them based upon their Domain or Access Point Group, with support
for stripping the domain from the incoming username. We also found supports for MAC address
authentication, which, while not the most secure method, can be used to authenticate devices that don't
support 802.1X security or other protocols supported by Elektron. Another notable feature is the
ability to block logins after multiple failed password attempts






10

Authentication settings in Elektron
In the Authorization settings, we could create custom polices. We could deny connections, assign
users to virtual LANs, append custom RADIUS response attributes or execute a script based upon
various triggers: login time, username, user group, access point group, media access control address
group or the result of a script. These provide the authorization functionality SMB networks usually
require, but don't provide the full customization ability larger or service provider networks might
require. In the Accounting section we found basic access and error logs, viewable only in the GUI and
not able to be sent to a database. We were impressed with the Event Handler feature that allows you to
easily enable notifications on events like logins, failed logins, password lockouts and errors. In the
main server settings Elektron supports remote administration so you can manage the server from other
PCs, and server replication in case you want to set up a backup server. Overall, Elektron is a solid,
attractive, and user-friendly server. Though the Getting Started section in the documentation could be
improved, generally it was informative and useful, and should be understandable by those less
experienced with RADIUS. Elektron is a great option for small and midsize networks.









11







3. Literatura

http://en.wikipedia.org/wiki/RADIUS
http://www.informatika.buzdo.com/pojmovi/tcpip8.htm
http://www.cisco.com/en/US/tech/tk59/technologies_tech_note09186a0080094e99.shtml
http://www.cisco.com/en/US/tech/tk59/technologies_tech_note09186a00800945cc.shtml
http://www.networkworld.com/reviews/2012/091012-radius-servers-wifi-security-test-261976.html?page=1













































12