FER

ZEMRIS

 

 

 

 

 

 

 

 

 

 

 

SIGURNA AUTENTIFIKACIJA U UNIX/LINUX OKOLINI

seminarski rad

 

 

 

 

 

 

 

 

 

 

Vatroslav Mihalj

0036350731

ag. god. 1999/2000.

mentor: prof. dr. sc. Leo Budin

 

 

 

 

 

 

 

Zagreb, 2000.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Heraklo savladava Kerbera

 

 

 

 

“KERBER – grč. Κέρβεροζ, u grč. mitologiji mnogoglavi pas, čuvar podzemlja. On je sin Ehidne, polužene-poluzmije, i giganta Tifona. Heziod zove Kerbera “okrutnim psom Hada koji ima glas poput zvuka bronce i pedeset glava”. U kasnijoj tradiciji ima samo tri glave, zmajsku grivu i rep. Njegova je dužnost oštro paziti da nitko ne umakne iz Hada. Jedno od Heraklovih junačkih djela bilo je to što je savladao Kerbera bez oružja i izveo ga na zemlju. Kad je K. ugledao sunčano svijetlo, počeo je pljuvati otrovnu pjenu, iz koje je izrastao otrovni ljutić. Heraklo je kasnije vratio Kerbera vladaru podzemlja Plutonu. K. je u antici često bio slikovno prikazivan. – U prenesenom smislu kerber (ili prema novolat. izgovoru cerber) znači strogog, nesmiljenog i nepotkupljivog vladara ili čuvara.”

                      “Opća enciklopedija”, sv. 4,

                       JLZ “Miroslav Krleža”, 1978.

 

SADRŽAJ

1       Uvod.......................................................................................................................................................................... 5

2       Mrežna okolina i njegovi nedostaci................................................................................................. 6

2.1     Opasnosti, nesigurnosti i prijetnje u mrežnoj okolini......................................................... 6

2.2     Autentifikacija u  distribuiranim sustavima......................................................................... 7

2.2.1      Autentifikacija............................................................................................................................................ 8

2.2.2      Autorizacija................................................................................................................................................. 9

3       Kerberos kao mrežna usluga.............................................................................................................. 10

3.1     Kratka povijest.......................................................................................................................................... 11

3.1.1      Pretpostavke koje su upravljale dizajnom Kerberosa ..................................................................... 12

3.2     Principal i format imena...................................................................................................................... 13

3.3     Vjerodajnice (credentials).................................................................................................................. 13

3.4     Ulaznica (ticket)....................................................................................................................................... 14

3.4.1      Početna (initial) ulaznica...................................................................................................................... 14

3.4.2      Ulaznica za dodjelu ulaznice (TGT)..................................................................................................... 14

3.4.3      Obnovljiva (renewable) ulaznica......................................................................................................... 14

3.4.4      Postdatirana (postdated) ulaznica ..................................................................................................... 15

3.4.5      Zamjenske (proxiable) ulaznica........................................................................................................... 15

3.4.6      Prosljediva (forwardable) ulaznica..................................................................................................... 15

3.4.7      Nevažeća (invalid) ulaznica ................................................................................................................. 16

3.5     Autentifikator (authenicator)....................................................................................................... 16

3.6     Osnovne naredbe........................................................................................................................................ 16

3.7     Kerberos klijent......................................................................................................................................... 17

3.8     Kerberos poslužitelj............................................................................................................................... 17

3.9     Aplikacijski poslužitelj........................................................................................................................ 17

3.10        Područje (realm).................................................................................................................................... 17

3.10.1        Nezavisna područja (independent realms) ................................................................................... 18

3.10.2        Poluzavisna područja (semi-independent realms) ...................................................................... 18

3.10.3        Hijerarhija područja........................................................................................................................... 19

3.11        Značenje sata......................................................................................................................................... 19

3.12        Autorizacija u Kerberosu ............................................................................................................. 19

3.13        Može li se UNIX baza lozinki korisnika pretvoriti u Kerberos bazu? ................ 20

4       Kerberos protokol.................................................................................................................................... 21

4.1     Kerberos baza podataka.................................................................................................................... 21

4.2       srvtab/keytab – autentifikacija poslužitelja................................................................ 22

4.3     Komunikacijski protokol.................................................................................................................... 22

4.3.1      Međukorisnička (user-to-user) autentifikacija................................................................................. 25

4.4     ASN.1 notacija.............................................................................................................................................. 26

4.5     Vremenski biljeg (timestamp) i važnost vremenskog okna............................................. 26

4.6     Enkripcija........................................................................................................................................................ 27

4.7     Kerberos sklopovlje: sigurnosni (secure) koprocesor IBM 4785.................................... 28

4.8     Kerberiziranje............................................................................................................................................. 28

4.9     Razlike između Kerberosa V4 i V5..................................................................................................... 29

4.10        Ograničenja i nedostaci  Kerberosa........................................................................................ 29

5       Kerberos, javni ključevi i World Wide Web............................................................................... 31

5.1     Javni ključevi u Kerberosu.................................................................................................................. 31

5.1.1      Protokol s javnim ključevima................................................................................................................ 32

5.1.2      Prednosti Kerberosa s javnim ključevima nad SSL protokolom..................................................... 33

5.2     Autentifikacija u WWW okolini...................................................................................................... 33

5.2.1      Projekt “Minotaur” – kerberizacija WWW-a...................................................................................... 34

5.2.2      Apache WWW poslužitelj i Kerberos..................................................................................................... 35

6       PAM – autentifikacija pomoću zamjenjivih modula............................................................. 36

6.1     Što je PAM?...................................................................................................................................................... 36

6.2     Sudionici u autentifikacijskom procesu.................................................................................... 36

6.3     Linux-PAM........................................................................................................................................................ 37

6.4     Konfiguracija Linux-PAM-a................................................................................................................. 38

6.5     PAM moduli.................................................................................................................................................... 39

6.6     Kerberos moduli......................................................................................................................................... 39

6.7     PAM za MS Windows NT: NI_PAM........................................................................................................ 39

6.8     Sigurnosni aspekti PAM-a..................................................................................................................... 40

7       SESAME – “Kerberos” s okusom Starog kontinenta............................................................. 41

7.1     SESAME arhitektura................................................................................................................................ 41

7.1.1      Klijent......................................................................................................................................................... 42

7.1.2      DSS poslužitelj i PAC certifikati........................................................................................................... 42

7.1.3      Aplikacijski poslužitelj........................................................................................................................... 43

7.1.4      Komponente za potporu (support)....................................................................................................... 44

7.1.5      Uloga (role).............................................................................................................................................. 44

7.2     SESAME protokol........................................................................................................................................ 44

7.3     Kriptografija u SESAME sustavu..................................................................................................... 47

7.4     UNIX aplikacije i SESAME........................................................................................................................ 47

7.4.1      Linux verzija.............................................................................................................................................. 48

7.5     Kerberos i SESAME...................................................................................................................................... 49

7.6     SSL vs. SESAME................................................................................................................................................ 49

7.7     Nedostaci i moguća poboljšanja SESAME arhitekture.................................................... 50

8       Mehanizmi alternativni Kerberosu................................................................................................. 51

8.1     Vatrozidovi (firewalls)......................................................................................................................... 51

8.2     Secure RPC....................................................................................................................................................... 51

8.3     SSL........................................................................................................................................................................ 53

8.4     AFS (Andrew File System)...................................................................................................................... 54

8.5     OSF DCE............................................................................................................................................................... 54

9       Bernie – implementacija SESAME arhitekture........................................................................... 56

9.1          Bernie protokol................................................................................................................................... 57

9.2     Nedostaci implementacije i moguća poboljšanja............................................................... 58

10     Zaključak.......................................................................................................................................................... 60

11     Leksikon/rječnik pojmova..................................................................................................................... 61

12     Literatura......................................................................................................................................................... 63

 

 

1         Uvod

 

         Razvojem mreža i distribuiranih računalnih sustava, korisnici i administratori počeli su se suočavati s raznim opasnostima specifičnim za takve sustave. Da bi se onemogućili napadi ili im se barem smanjio broj, razvijeni su sustavi koji nude usluge autentifikacije (authentication), autorizacije (authorization) i baratanja podacima vezanim uz korisničke račune (accounting).

         Naslov sugrerira da je u ovom radu riječ o “sigurnim” metodama autentifikacije, u smislu oslanjanja na (složene) razmjene poruka i korištenje kriptografije. One su suprotstavljene metodama koje se uvjetno mogu nazvati “nesigurnim” ili nedovoljno sigurnim za umrežene sustave, kao što je npr. par korisničko ime-lozinka koji se prenosi kroz mrežu u jasnom tekstu (nelriptiran).

         Jedan od prvih takvih sustava bio je Kerberos. Razvijen na MIT-u sredinom osamdesetih godina ovog stoljeća, poslužio je kao uzor za velik broj sličnih sustava.

         U daljnjem tekstu naglasak je stavljen upravo na Kerberos kao klasičan autentifikacijski sustav. Opisana je i europska sigurnosna arhitektura kompatibilna s Kerberosom nazvana SESAME, sustavi koji omogućuju indirektnu suradnju autentifikacijskih usluga i aplikacija (poput autentifikacije zasnovane na modulima – PAM), te rješenja koja se mogu nazvati alternativom, odnosno konkurencijom Kerberosu (Sun SecureRPC, vatrozidovi, SSL itd).

         Namjera ovog rada nije pružanje detaljnog i sveobuhvatnog uvida u najbolja sigurnosna rješenja. Ovdje su opisane danas najpopularniji i najrašireniji sigurnosni sustavi u obliku sažetka koji upućuje na daljnje refernece.

        

 

 

 

 

2         Mrežna okolina i njeni nedostaci

2.1        Opasnost, nesigurnost i prijetnje u mrežnoj okolini

Prijetnja se definira kao okolnost (circumstance), stanje (condition) ili događaj (event) koji može naškoditi osoblju ili mrežnim resursima u obliku uništavanja (destruction), razotkrivanja (disclosure) ili modifikacije podataka, uskrate usluge (denial of service), prijevare (fraud) i zlouporabe (abuse) ([06]).

         U otvorenom računalnom mrežnom okruženju, radne stanice ne mogu biti pouzdane kod prezentiranja identiteta svojih korisnika mrežnim uslugama. Većina lokalnih mreža (LAN) zasnovana je na Ethernetu, koji prenosi informacije između računala u blokovima znakova zvanim paketi. Svaki paket ima u zaglavlju adresu primatelja i pošiljatelja. Kako su ti sustavi su bazirani na “pristojnosti” i “dobrim namjerama”, nitko ne bi smio mijenjati adrese ili sadržaj paketa niti krivotvoriti svoj identitet. U prošlosti, kad su mreže bile u nastanku, tvorila su ih prvenstveno velika UNIX računala. Nije bilo lako fizički priključiti vlastita računala na mrežu. Nitko osim administratora sustava nije imao ovlaštenja za predstavljanje pod drugim imenom ili prisluškivanje paketa. No, u osamdesetim godinama radne stanice su postale široko dostupne i počelo se s masovnijim umrežavanjem. Osnovne pretpostavke o povjerenju postale su upitne. To naročito dolazi do izražaja u lokalnim mrežama, gdje su računala priključena na isti fizički vod te nema zapreka da bilo koji paket bude pročitan od bilo kojeg računala u lokalnoj mreži

         Posljedica navedenog je nemogućnost da primatelj bude siguran tko je poslao primljeni paket, te su umreženi sustavi ugroženi na više načina:

·         prisluškivanjem (eavesdropping attack) – napadač može čitati pakete koji su namjenjeni nekom drugom računalu te na taj način doći do osjetljivih informacija

·         lažnim predstavljanjem – napadač konfigurira računalo da se ono pretvara da je neko drugo i na taj način vara druga računala koja mu “vjeruju” ili se pak predstavlja kao neki korisnik (npr. provalivši na njegov korisnički račun)

·         modifikacijom paketa (packet modification) – paketi namijenjenu nekom drugom sustavu se presreću i njihov sadržaj se mijenja, ponekad se i uništavaju

·         ponovnim odašiljanjem snimljenih starih paketa (packet replay) – komunikacija se prisluškuje, odaslani paketi se snime i upotrijebe kasnije; vrlo ozbiljna prijetnja u slučaju kad aplikacije razmjenjuju autentifikacijske poruke, jer napadač može odašiljanjem ispravnih, ali starih paketa s ispravnih autentifikacijskim porukama dobiti pristup sustavu ili nekim njegovim resursima

Za ilusutraciju i lakše razumijevanje može poslužiti nekoliko primjera. Prvi neka bude klasičan klijent-poslužitelj protokol: telnet. Kad se netko telnetom prijavljuje za rad na udaljenom računalu, šalje svoje korisničko ime i lozinku. Oboje se prenosi kroz lokalnu mrežu kao i bilo koji drugi paket, tako da ga bilo koje drugo računalo može (u zloj namjeri) pročitati. U principu, prijenos paketa preko čitave mreže ne smeta računalima, jer ih računala ignorira ako nisu namijenjeni njima. Problem je u tome što se sučelja lokalnih mreža mogu vrlo lako preprogramirati da čitaju svaki paket. Svi takavi programi nisu stvoreni niti pokrenuti s lošim namjerama, jer analizatori mreža rade na taj način. Opasnost leži u tome što se takvi programi mogu zlouporabiti za prisluškivanje mrežnog prometa bez znanja (a moguće i na štetu) ostalih korisnika.

         Za ovakvo nešto napadač mora imati privilegije administratora, što je bila glavna zapreka i zaštita u počecima mreža. No danas je relativno je lako prigrabiti te privilegije na nekoj od mnogobrojnih radnih stanica ili se ilegalno priključiti na sam fizički vod (vampirski priključak, vampire transceiver).

         Skup “r” (remote) naredbi (rlogin, rsh i rcp) je još jedan primjer slabe točke u mrežnoj sigurnosti, proizašle iz dobre namjere. Program rlogin prijavljuje korisnika na udaljeno računalo, rsh (remote shell) se spaja na udaljeni sustav i izvršava specificiranu naredbu, a rcp kopira datoteke između sustava. Tvorci su željeli korisnicima olakšati snalaženje u svijetu velikih domaćinskih računala (hosts), omogućujući im da se s nekih računala prijave rad na drugim, udaljenim računalima (remote hosts) bez lozinke. Ta udaljena računala nazvana su  pouzdanim domaćinskim računalima (trusted hosts). Bilo koje računalo na kojem korisnik ima korisnički račun (account) s istim korisničkim imenom može se proglasiti pouzdanim domaćinskim računalom (trusted host) navođenjem u datoteci .rhosts. Korisnik može imati takvu datoteku na bilo kojem računalu na kojem ima korisnički račun. Na taj način željelo se olakšati rad time što se lozinka traži samo kod prijave na neko od tih računala i omogućuje automatska prijava za rad na bilo kojem pouzdanom domaćinu. Korisnik ne gubi vrijeme upisujući lozinke kad se poželi prijaviti na neko drugo računalo. Dovoljno je znati lozinku na jednom od računala, umjesto pamtiti sve lozinke. Logika kojom su se autori rukovodili bila je: ako znaš lozinku, ti si autentificiran; računala u .rhosts datoteci vjeruju jedno drugom polazeći od principa da nitko od njih ne može biti kompromitiran; ako te jedno računalo autentificiralo, ostala mogu vjerovati njegovoj izjavi. Ako napadač uspije prikriti svoj originalni identitet i predstaviti se kao netko drugi, omogućen mu je nesmetan i lak pristup sustavu jer mu ovaj “vjeruje”.

         No ovaj pristup ima i svojih (uvjetno rečeno) pozitivnih strana: kako se ne zahtjeva lozinka za pristup, ona se ne može saznati prisluškivanjem. Ali taj princip upravo je i glavni problem: ne može se vjerovati radnom računalu (host) ni korisnicima na njemu.

         Programi rexec i rexecd omogućuju udaljeno izvršavanje (remote execution). Za razliku od “r” komandi, ne koristi se mehanizam pouzdanih domaćinskih računala (trusted hosts). Klijent šalje poruku u jasnom (nekriptiranom) tekstu koja sadržava korisničko ime, lozinku i naredbu koja se treba izvršiti. Zlonamjernik treba samo pročitati nezaštićene podatke iz paketa.

         Neke od slijedećih postavki mogu smanjiti rizike ([29]):

·         ograničiti pristup – da bi se zaštitili od prisluškivanja, ne smije se dopustiti napadaču da uopće dobije pristup mreži (zaključavanje opreme u ormare u posebnim sobama, onemogućiti pristup s priključaka koji se inače ne koriste itd)

·         ograničiti fizičku dostupnost mrežnog voda radi zaštite od ilegalnih fizičkih priključaka

·         ako je moguće, uporabiti optička vlakna – teže je priključiti se na njih

·         uporaba enkripcije – ako napadač ne poznaje sustav enkripcije niti ključ, praktično mu je nemoguće razumjeti ono što prisluškuje ili slati krivotvorene pakete

·         uporaba podmreža – svaka s vlastitim domenama i poslužiteljima, s ograničenim dijeljenim resursima i sl. (da bi se smanjila opasnost ukoliko bude provaljeno na neko od računala)

2.2        Autentifikacija u  distribuiranim sustavima

         Od suvremenog mrežnog okružja danas se zahtjeva da kontrolira pristup samoj mreži, da kontrolira pristup resursima i uslugama koje pruža mreža i da može provjeriti pružaju li mehanizmi za kontrolu tih pristupa odgovarajuću zaštitu ([06]).

U mrežnom okružju može se govoriti o tri vrste pristupa ili prijava za rad. Prva je lokalna prijava. Korisnik se autentificira lokalnom sustavu (zvanom klijent), najčešće lozinkom. Druga je prijava na udaljeni sustav (remote login): korisnik se s lokalnog sustava prijavljuje na udaljeni, npr. telnetom. Treća vrsta pristupa koja zahtjeva autentifikaciju je klijent/poslužitelj zahtjev.

         Provjera korisnikovog identiteta pomoću lozinke, uobičajena u tradicionalnim računalnim sustavima, pokazala se neprikladnom za mrežno okruženje. Lozinka se može lako saznati prisluškivanjem. Time nije zadovoljena osnovna pretpostavka da samo korisnik zna svoju lozinku. Korištenjem autentifikacijskih protokola implementiranih kao usluge u računalnoj mreži, može se eliminirati veliki broj potencijalnih sigurnosnih rupa.

Protokol se može definirati kao precizno određen slijed koraka u komunikaciji i proračunavanju, a sastoji se od komunikacijskih i izračunskih koraka. Komunikacijski korak prenosi poruke od jednog principala (pošiljatelj) do drugog principala (primatelj).  Izračunski korak (computation step) osvježava ili nadopunjava (updates) unutarnje stanje principala. Komunikacijski korak je npr. “korisnik šalje ime poslužitelju”, a izračunski “poslužitelj treba izračunati nešto iz lozinke”. Prilikom završetka mogu se identificirati dva različita stanja: jedno koje predstavlja uspješnu autentifikaciju i drugo koje predstavlja neuspjeh ([06]).

Principali su sustavi koji se koriste da se autentificira korisnik poslužitelju ili usluzi. Svaki sustav definira neki skup principala. Neki od najčešćih su:

·         korisničko ime (username)– identitet korisnika

·         ime domaćinskog računala (hostname) – identitet domaćinskog računala (host)

·         klijent (client) – računalo koje zahtjeva uslugu od nekog radnog (domaćinskog) računala u ime korisnika

·         poslužitelj (server)– domaćinsko računalo koje pruža usluge

U distribuiranim sustavima u mreži mora postojati dio s informacijama koje se koriste za autentifikaciju korisnika. To može biti poseban poslužitelj, obično nazvan autentifikacijski poslužitelj ili poslužitelj za dodjelu ključeva – key distribution server . On sadržava bazu podataka u kojoj su pohranjeni javni, privatni ili tajni ključevi korisnika, klijenata i poslužitelja. Oni moraju vjerovati da su informacije koje dobivaju iz te baze istinite, tj. takav poslužitelj je pouzdana treća strana (trusted third party). Tajni podaci (poput ključeva i lozinki) se privremeno pohranjuju u nekom dijelu računala (klijenta, poslužitelja ili oba), što znači da moraju postojati mehanizmi za njihovu zaštitu.

Autentifikacijski sustavi u distribuiranim okolinama temelje se na uporabi kriptografskih tehnika da bi se napadačima dalo malo ili nimalo informacija koje bi oni mogli zlouoprabiti. Informacije koje se koriste za autentificiranje principala imaju oblik ulaznica ili certifikata. Ulaznice same po sebi ne potvrđuju autentifikaciju. Udružujući ih s nekim oblikom autentifikatora (autheticator) potvrđuje se identitet dajući vremensku referencu uporabe, tj. vremenski okvir ili okno (time-frame) unutar kojeg su valjane. Ulaznice istječu (tj. postaju nevaljane) da bi se spriječila uporaba prije ili poslije željenog vremena. Ona može biti zlouporabljena od napadača samo unutar vremena svoje valjanosti. Kreira ih pouzdan (trusted) principal.

U ulaznicama se obično pojavljuje:

·         lozinka principala

·         javni ključ principala, poznat svima

·         privatni ključ, poznat samo korisniku, čini par s javnim ključem

·         tajni ključ, dijeljen između dva principala, s relativno dugim vremenom valjanosti

·         konverzacijski (conversion) ključ, obično ograničen na duljinu trajanja sjednice (session) ili valjan određen broj sati, dijeljen između dva principala

2.2.1       Autentifikacija

         Autentifikacija je proces verificiranja identiteta sudionika koji je generirao neke podatke i integriteta podataka. Principal (principal) je strana čiji se identitet utvrđuje, a verifikator (verifier) je strana koja zahtjeva jamstvo o principalovom identitetu. Integritet podataka je jamstvo da su primljeni isti podaci koji su generirani.

         Autentifikacijski mehanizmi razlikuju se u jamstvima koja pružaju: neki potvđuju da je podatke generirao principal u nekom trenutku u prošlosti, neki da je principal bio nazočan kad su  podaci bili poslani. Mehanizmi se razlikuju i u broju verifikatora: neki podržavaju jednog verifikatora po poruci, neki višestruke verifikatore. Treća razlika je da li mehanizmi podržavaju nerazdvajanje (non-repudiation), mogućnost verifikatora da dokaže  trećoj strani da je poruku proizveo s principalom ([14]).

         Budući da ove razlike djeluju na performanse, važno je razumjeti zahtjeve aplikacije kod izbora metode.

         Najkonvencijalniji višekorisnički sustavi traže da se korisnik identificira prije nego koristi usluge. U okruženju koje se sastoji od mreže koja povezuje klijente s uslugama, mrežna usluga ima odgovarajuću potrebu za identificiranjem i autentificiranjem korisnika. Za razliku od višekorisničkih sustava, gdje zaštitni zid razdvaja operacijski sustav od korisnika, radna stanica je potpuno pod kontrolom korisnika. On može modificirati njen operacijski sustav ili čak zamijeniti samo računalo. To rezultira nemogućnošću oslanjanja mrežne usluge na operacijski sustav radne stanice kad ona obavlja autentifikaciju.

         Povjerljivost ili zaštita tajnosti (confidentiality) je zaštita informacije od razotkrivanja subjektima kojima ta informacija nije namjenjena. Većina jakih autentifikacijskih metoda opcionalno nude i povjerljivost.

         Tri su glavna tipa autentifikacije u distribuiranim sustavima ([30]):

·         autentifikacija sadržaja poruke (message content) – moguće je provjeriti da li je primljena poruka uistinu ona koja je poslana; postiže se kriptografskim sumiranjem sadržaja (cryptographic checksum) zvanim MAC (Message Authentication Code) ili korištenjem digitalnog potpisa pomoću javnog ključa (public-key digital signature)

·         autentifikacija porijekla poruke (message origin) – može se utvrditi da je stvarni pošiljatelj onaj za kojeg se u poruci tvrdi da je pošiljatelj, npr. uporabom simetričnog kriptosustava (zahtjeva treću stranu kojoj oba sudionika vjeruju); u asimetričnom kriptosustavu uporaba javnog ključa ili digitalnog potpisa dokazuje porijeklo

·         autentifikacija općenitog identiteta (general identitiy) – može se utvrditi da je identitet principala onaj koji se tvrdi

         Autentifikacija nije nešto što je samo sebi svrha, nego vrsta alata, a osnovna joj je namjena zaštita od lažnih zahtjeva za vezom.

2.2.2       Autorizacija

         Autorizacija je proces kojim se utvrđuje da li principal ima dozvolu za izvođenje neke operacije. Obično se provodi nakon što je principal autentificiran te se može temeljiti na informacijama koje su lokalne za verifikatora ili na autentificiranim iskazima drugih.

         Kerberos autentifikacijski model ([07]) daje samo potvrdu identiteta klijenta koji zahtjeva uslugu. Sam po sebi ne daje nikakve informacije da li je klijent autoriziran, da li ima dozvolu koristiti tu uslugu.Tri su forme u kojima bi se autorizacija mogla integrirati u Kerberos model:

·         Kerberos baza podataka – mogla bi sadržavati autorizacijske informacije za svaku uslugu; ulaznice za uslugu dodjeljuju se autoriziranim korisnicima te usluge

·         posebna autorizacijska usluga (separate authorization service) – održava se autorizacijska lista informacija za svaku uslugu i dozvoljava se klijentu da pribavi zapečaćeni (sealed) certifikat; krajnjoj usluzi bi se pokazao taj certifikat

·         svaka usluga bi mogla održavati vlastite autorizacijske informacije – uz opcionalnu pomoć usluge koja sprema dijeljene javne liste i pribavlja certifikate o članstvu u javnoj listi

         Prva opcija stavlja veliku, dinamički nadopunjavanu bazu podataka nasuprot maloj, rijetko mijenjanoj, koja sadrži dobro čuvanu bazu enkripcijskih ključeva. Ovo rješenje zahtjeva kompromis između operacijskih parametara (npr. veličina memorije) i fizičke sigurnosti. Primjenjujući ju, sve aplikacije mogu koristiti jedan model autorizacije.

         Drugo rješenje odjeljuje autorizacijsku bazu podataka od autentifikacijske, te se time olakšava odvojena administracija. Rezultat je jednostavnija i manja autentifikacijska usluga, što bi ju trebalo učiniti pouzdanijom i sigurnijom. Posljedica je izvanredna kompleksnost (i time moguća krhkost) protokola u interakciji između klijenta i usluga (autentifikacijskih, autorizacijskih i ciljnih).

         Kerberos autorizacijski model baziran je na principu da svaka usluga najbolje zna tko bi trebali biti njeni korisnici i koji bi oblici autorizacije bili prikladni.

 

 

 

 

 

3         Kerberos kao mrežna usluga

         Kerberos je mrežni autentifikacijski sustav koji se koristi u fizički nesigurnim mrežama. On je treća strana kojoj oba sudionika u “razgovoru” vjeruju i on potvrđuje identitet svakog od njih. Dokazivanjem identiteta sprečava se prisluškivanje i napad ponovnim korištenjem starih paketa (replay attack). Ne oslanja se ni na autentifikaciju koju nudi operacijski sustav na radnom računalu (host), niti na mrežnu adresu.

         Kerberos je sustav koji traži unos lozinke samo jednom (single sign-on), na početku sjednice (session). Ona se ne prenosi preko mreže nego se klijentskom računalu prepušta manipuliranje lozinkom. Osjetljivi (tajni) podaci se mrežom prenose kriptirani. Za dekripciju je potrebno znanje lozinke tog korisnika, jer se njegov tajni ključ izračunava iz lozinke.

Kerberos je razvijen s ciljem da se omogući mrežnim aplikacijama siguran način identifikacije. Proces započinje klijent, odnosno u Kerberos terminologiji principal. On pokreće razmjenu poruka između triju strana da bi se kontaktirana strana (poslužitelj) uvjerila u klijentov identitet. Ta potvrda identiteta ima oblik ulaznice, koja identificira klijenta, i autentifikatora (autenticator), koji služi da se ulaznica validira i spriječi ponovna uporaba stare ulaznice (replay) od strane napadača. Ulaznica je valjana samo u odgovarajućem intervalu, zvanom razdoblje valjanosti (lifetime). Kad razdoblje valjanosti istekne, ulaznica istječe (postaje nevaljana). Ukoliko se žele daljnje usluge, treba zatražiti novu ulaznicu. Valjana ulaznica može se koristiti (svaki put uz svježi autentifikator) proizvoljan broj puta, sve dok ne istekne (postane nevaljana).

         Polazna točka je pretpostavka da svaki paket koji putuje kroz mrežu može biti pročitan, modificiran ili ubačen po volji. Kerberos dopušta procesu koji radi u ime principala da dokaže svoj identitet verifikatoru (nekom poslužitelju) bez slanja podataka koji bi dozvolili napadaču ili verifikatoru da se kasnije pretvara da je principal ([14]). Također, podacima je osiguran integritet toka (detekcija modifikacije) i tajnost (osiguranje od neautoriziranog čitanja) uporabom kriptografskih metoda ([01]). Treba primjetiti da Kerberos štiti samo lozinke i druge povjerljive informacije, a ne sve podatke koji prolaze kroz mrežu. Tako će npr. Kerberos verzija FTP-a kriptirati korisničko ime i lozinku, ali ne i sadržaj datoteka koje se prenose.

         Rad je zasnovan na opskrbljivanju principala (klijenata ili usluga) ulaznicama i tajnim kriptografskim ključevima za sigurnu komunikaciju. Ulaznice se koriste da se principali identificiraju drugim principalima. Korištenjem serije kriptiranih poruka verifikatoru se dokazuje da klijent radi u korist određenog korisnika. Glavni cilj je podrška i jednosmjerne (one-way) i uzajamne (mutual) autentifikacije principala

         Uzajamna autentifikacija i sigurna komunikacija između principala u otvorenoj mreži provodi se tako da Kerberos proizvodi tajne ključeve za podnositelje zahtjeva i osigurava mehanizam sigurnog prosljeđivanja tih ključeva kroz mrežu. Sam po sebi ne ne osigurava autorizaciju ni manipuliranje korisničkim računima (accounting). Ti su aspekti bili u početnom planu jednako važni kao i autentifikacija, no u daljnjim planovima su postali pomalo zanemareni

         Da bi se mogle iskoristiti pogodnosti i sigurnost koju Kerberos pruža, aplikacije se trebaju zamjeniti “kerberiziranim” verzijama, tj. verzijama koje razumiju i surađuju u Kerberos protokolu. Distribucije Kerberosa donose kerberizirane verzije najpopularnijih aplikacija, kao što su rlogin, telnet, ftp itd.

         Kerberos nudi različite nivoe zaštite, dopuštajući aplikacijskom programeru da odabere onaj koji smatra prikladnim u odnosu na zahtjeve aplikacije[1]. Neke aplikacije traže da se autentičnost provjeri samo na početku i smatraju da daljnje poruke s te adrese dolaze od autentificirane strane (npr. to radi mrežni datotečni sustav u MIT mreži). Druge aplikacije pak zahtjevaju autentifikaciju svake poruke, ne mareći da li je poruka razotkrivena ili ne. Za njih Kerberos nudi “sigurne poruke” (safe messages, KRB_SAFE). Najviši nivo predstavljaju “privatne poruke” (private messages, KRB_PRIV), gdje je svaka poruka i autentificirana i kriptirana. Koriste se npr. za slanje lozinki preko mreže ([08]).

         Kerberos poslužitelj bavi se samo visoko osjetljivim informacijama, poput lozinki, ključeva i sl. Informacijama koje nisu osjetljive u smislu sigurnosti (prava imena, telefon itd.) bavi se drugi poslužitelj, Hesiod poslužitelj. Informacije s tog poslužitelja mogu se nekriptirane slati preko mreže (npr. finger programom želi se saznati ime nekog korisnika ili njegov broj telefona).

         Važno je napomenuti da Kerberos pretpostavlja da se komunikacija odvija između pouzdanih računala i nepouzdane mreže. Ako je računalo nepouzdano (npr. operacijski sustav modificiran), Kerberos je bespomoćan. Ako napadač ukrade lozinku, može oponašati tog korisnika jer je lozinka temeljni dokaz identiteta korisnika u Kerberosu. Ako je sigurnost Kerberos poslužitelja ugrožena, cijelo područje (realm) kojem taj poslužitelj pruža usluge je ugroženo.

         Praktički gledano, Kerberos  se uglavnom koristi u protokolima aplikacijskog sloja (ISO OSI referentni model, sloj 7), npr.  telnet ili FTP, da bi se osigurala sigurnost korisnika i računala. Rjeđe se koristi kao implicitni autentifikacijski sustav toka podataka ili RPC mehanizam (ISO OSI model sloj 6). Također, može biti korišten i u nižim slojevima za sigurnost između čvorova, u protokolima poput IP-a, UDP-a ili TCP-a (ISO OSI model slojevi 3 i 4), iako su te implementacije jako rijetke ([01]).

         Kako mnogi “glupi” terminali i većina X-terminala ne razumiju Kerberos protokol, njihovi kabelski spojevi ostaju neosigurani i podložni napadima.

3.1        Kratka povijest

         Godine 1983. na MIT-u, u suradnji s IBM-om i DEC-om, započelo je provođenje projekta Athena. Cilj je bio uvođenje računala u dodiplomsku nastavu. U početku se radilo s 50-ak DEC VAX 11/750 s 4.2BSD, no nakon par godina počelo se integrirati i radne stanice u mrežu. Uskoro su došli do izražaja svi prije  spomenuti problemi. Mreža je bila dostupna svima u krugu sveučilišta i ništa nije moglo spriječiti korisnike da prisluškuje podatke koji putuju kroz mrežu.

         Na taj način lako se moglo saznati administratorske lozinke, a većina računala su bili PC/AT računala, nezaštićeni “glupi” strojevi. Rješenje je bio Kerberos – autentifikacijski sustav koji koristi DES kriptosustav za autentifikaciju i razmjenu osjetljivih informacija preko mreže. Na taj način od prisluškivanja nema koristi, a lažno predstavljanje se može razotkriti.

         U mreži u kojoj korisnici zahtjevaju usluge od mnogih računala, može se zauzeti jedan od tri stava prema kontroli pristupa:

1.       ne poduzimati ništa – pouzdati se da će stroj na koji je korisnik prijavljen spriječiti neautorizirani pristup

2.       zahtjevati od domaćinskog računala (host) da dokaže svoj identitet, te vjerovati njegovim izjavama o korisnikovom identitetu

3.       zahtjevati od korisnika dokazivanje svog identiteta za svaku zatraženu uslugu

Prvi pristup je zadovoljavajući u zatvorenoj radnoj okolini, gdje su strojevi pod strogom kontrolom. Sva radna računala koja komuniciraju preko mreže su pod kontrolom. U otvorenijoj okolini može se odabrati da se vjeruje samo računalima pod kontrolom organizacije. Tada svako računalo mora dokazati svoj identitet, obično provjerom Internet adrese s koje se uspostavlja komunikacija. Za Athena radnu okolinu na MIT-u odabran je treći pristup. Naime, primaju se zahtjevi i od računala koja nisu pod kontrolom organizacije, nad kojima korisnici imaju potpunu kontrolu. Korisnik dokazuje svoj identitet kad zahtjeva uslugu. Poslužitelj također mora dokazati svoj identitet, jer netko može krivotvoriti adresu računala.

         MIT nije bio zadovoljan tadašnjim industrijskim standardom poznat kao “autentifikacija umetanjem” (authenication by assertion), jer su smatrali da ova metoda nudi nizak nivo zaštite u usporedbi s potpunom kerberizacijom ([29]). U toj metodi, korisnik pokreće program koji pristupa mrežnoj usluzi, a drugi program dokazuje usluzi da radi u ime korisnika. Otkad je u njihovom krugu sveučilišta proradio sustav baziran na Kerberosu, poticali su slobodnu uporabu i širenje Kerberosa kao puno boljeg i sigurnijeg rješenja.

         Nizak nivo sigurnosti dotadašnjeg standarada ilustrirali su primjerom ([36]). Ako se korisnik služi naredbom rlogin za spajanje na računalo navedeno u njegovoj .rhosts datoteci i ima na njemu isto korisničko ime, udaljeno računalo neće tražiti njegovu lozinku. To je opasno ako napadač uspije uvjeriti rlogin program da je on legitman korisnik ili ako napiše promijenjenu verziju rlogina koja će potvrditi njegov identitet. Drugi ekstrem bio bi tražiti lozinku za svaki pristup mrežnoj usluzi, što je nepogodno zbog barem dva razloga. Prvi je što oduzima previše korisnikovog vremena. Drugi razlog je putovanje lozinke u jasnom obliku kroz mrežu ako se korisnik želi prijaviti s jednog udaljenog računala na drugo udaljeno računalo. Zbog toga razvijene autentifikacijske metode temeljene na kriptografiji. Napadač može prisluškivati, no ne dobiva nikakve informacije koje bi mu pomogle da se lažno predstavi

         Kerberos je dodatak na sustav i može biti korišten u kombinaciji s bilo kojim postojećim mrežnim protokolom.

3.1.1       Pretpostavke koje su upravljale dizajnom Kerberosa [2]

·         zahtjev za autentifikacijom je dvosmjeran: usluga može sa sigurnošću saznati tko je klijent, a klijent (ukoliko to želi) može biti siguran da se koristi ispravna usluga

·         lozinke u jasnom tekstu ne smiju se prenostiti kroz mrežu

·         lozinke u jasnom tekstu ne smiju biti pohranjene u poslužiteljima

·         klijent treba lozinkama u čistom tekstu rukovati što je kraće moguće i one kasnije moraju biti uništene

·         dizajn treba ograničiti bilo kakve autentifikacijske kompromise koji se tiču trenutne sjednice (session) ili trenutnog korisnika

·         autentifikacija ima razdoblje valjanosti ograničeno na jednu prijavu za rad

·         mrežna autentifikacija mora teći neprimjetno u normalnim slučajevima; zahtjevanje lozinke pri prijavi treba biti jedina točka u kojoj korisnik primjećuje da se provodi autentifikacija

·         dizajn bi trebao minimizirati napor potreban da se modificiraju mrežne usluge koje su ranije koristile druge načine autentifikacije

         Pretpostavljena fizička i radna sigurnosna okolina bi (prema planu) trebala uključiti:

·         radne stanice (privatne i javne) – javne se nalaze u zonama s minimalnom fizičkom sigurnošću; privatne su pod fizičkom i administrativnom kontrolom pojedinaca bez odgovornosti administracije koja se brine o centralnoj mreži

·         sveučilišna mreža bez enkripcije – sastoji se od lokalnih mreža raznih tipova povezanih preko gatewaya na središnju mrežu (backbone net); lokalne mreže su fizički široko razbacane i ranjive na napade koji se tiču sigurnosti; središnja (backbone) i gatewayi su u zaključanim ormarima i time umjereno sigurne

·         centralni poslužitelji su u zaključanim sobama, pretpostavlja se da rade u osrednje sigurnim uvjetima s pouzdanim i poznatim softverom

·         mali broj centralnih poslužitelja (npr. Kerberos poslužitelj) radi u uvjetima koji se smatraju sigurnim

         Krenulo se od principa da okolina nije prikladna za osjetljive podatke ili operacije visokog rizika, npr. bankovne transakcije ili povjerljive podatke. Rizicima su se smatrali prvenstveno nekontrolirana uporaba resursa od strane neautoriziranih sudionika, povreda integriteta bilo sustava bilo njegovih resursa, te općenito povrede privatnosti kao što su pregledavanje nečijih datoteka. Smatralo se da primarne prijetnje dolaze od korisnika s krivotvorenim identitetom na radnim stanicama. Kako je radna stanica pod potpunom kontrolom korisnika, on može pretvarati da je neki drugi korisnik ili čak drugo računalo (host).

         Privatnost podataka koji su se prenosili mrežom smatrao se niskim prioritetom, osim u slučajevima kad je bilo potrebno onemogućiti kršenje integriteta (prenošenje lozinki).

3.2        Principal i format imena

Korisnik ili usluga koji se mogu autentificirati nazivaju se principalima (principal). Svaki principal ima ime koje ga jednoznačno označava. Autentifikacija principala je proces dokazivanja svog identiteta komponenti sustava koja zahtjeva taj sigurnosni korak – verifikatoru (verifier). Na taj način se dodjeljuju prava pristupa informacijama i uslugama, u ovisnosti tko je taj principal. To važi i za ljude kao korisnike i za aplikacije. Za ljude se proces autentifikacije sustavu neformalno naziva “prijava na sustav” (logging on) ([48]).

Principali u Kerberos modelu su korisnik, klijent, autentifikacijski poslužitelj, poslužitelj za dodjelu ulaznica i poslužitelj koji pruža zatraženu uslugu. Klijent radi u ime korisnika.

Identifikator principala sastoji se od tri komponente ([07]): principalskog imena (principal name), imena instance (instance name) i imena područja (realm name). Svaka usluga i svaki klijent imaju jedinstveno principalsko ime. Ime instance je labela koja omogućuje da isti klijent ili usluga postoji u nekoliko oblika koji zahtjevaju različitu autentifikaciju (npr. rlogin usluga na jednom računalu je različita od rlogin usluge na drugom; netko može biti i korisnik i administrator na istom računalu, no tada ima različite ovlasti). Svaka instanca je, makar bila pridružena istom imenu korisnika, odvojen unos u Kerberos bazi. Korisnik obično radi koristeći ime s null instancom (tj. ispuštena je). Ime područja definira se da bi se identificirali nezavisni Kerberos poslužitelji. Par {principalsko ime, ime instance} jedinstven je samo unutar jednog područja. Ime područja obično daje radna stanica na kojoj korisnik radi, no autentifikacija se može zatražiti i od poslužitelja u nekom drugom području ([07]).

U verziji 4 principalsko ime i ime instance odvojeni su točkom (“.”). Ako “.” nije uključena u ime kojim se korisnik predstavlja prilikom prijave, smatra se da je instanca null. Ako se želi autentifikacija u drugom području (realm), a ne u području inicijalnom za radnu stanicu, iz imena dodaje se znak “@” i ime područja:

Kerberos login: VMihalj.admin@KRB-TEST.FER.HR

U verziji 5 format imena je oblika: komponenta/komponenta/komponenta@realm. Izrazi “ime” i “instanca” još uvijek se koriste za prvu i drugu komponentu. U principalima u kojima se koristi ime računala kao instanca,  V4 koristi kratko ime, bez imena domene. V5 koristi puno ime domene ([20]).

         Prostor imena (namespace) koji se koristi za Kerberos autentifikaciju i autorizaciju nezavisan je od imena korisnika ili usluga na određenom domaćinskom računalu (host) i bilo kakvih konvencija specificiranih operacijskim sustavom. Svako računalo može prevesti Kerberos identifikatore principala u vlastita lokalna imena.

3.3        Vjerodajnice (credentials)[3]

Vjerodajnice sadrže sigurnosne (security) atribute principala, razdoblje valjanosti (lifetime) i još neke podatke. Koriste se za dobivanje dozvole pristupa zaštićenim objektima, za identifikaciju stvaratelja poruke i za obračunavanje (accounting) principalovih akcija ([48]).

Dva su tipa vjerodajnica u Kerberos autentifikacijskom modelu: ulaznice i autentifikatori. Oba se temelje na enkripciji pomoću tajnih ključeva, no kriptirani su različitim ključevima.

Ulaznice se koriste za sigurno prosljeđivanje identiteta osobe kojoj je ulaznica izdana. Autentifikator sadrži dodatne informacije pomoću kojih se može utvrditi da je klijent koji je predočio ulaznicu isti onaj kojem je ulaznica izdana (uspoređivanjem podataka iz ulaznice i autentifikatora). Za razliku od ulaznice koja se može iskoristiti više puta (da bi klijent dobio više puta pristup potrebnoj usluzi), sve dok ne istekne, autentifikator se može iskoristiti samo jednom. Svaki put kad klijent želi uslugu, mora se generirati novi. To ne predstavlja problem, jer autentifikator stvara klijent ([09]).

3.4        Ulaznica (ticket)

         Ulaznica je vrsta certifikata koji dodjeljuje autentifikacijski poslužitelj (dio Kerberos poslužitelja). To je niz bajtova koji sadrži razne informacije. Kriptirana je tajnim ključem za određenu uslugu (tj. tajnim ključem poslužitelja koji pruža tu uslugu) i principal ju koristi da bi dokazao da je ono što tvrdi. Ulaznica između ostalog sadrži sjednički ključ (generira se kao niz slučajnih znakova) koji će biti korišten za autentifikaciju principala verifikatoru, ime principala kojem se sjednički ključ izdaje, te razdoblje valjanosti sjedničkog ključa. Nakon isteka tog vremena ključ više nije valjan. Ulaznica se ne šalje direktno verifikatoru, nego klijentu koji ju proslijeđuje verifikatoru kao dio aplikacijskog zahtjeva (application request). Kako je ulaznica kriptirana tajnim ključem poslužitelja, koji je poznat autentifikacijskom poslužitelju i određenom verifikatoru, klijent ju ne može modificirati a da se to ne detektira ([14]).

         Ulaznice se mogu ugraditi u praktički bilo koji protokol, na taj način dozvoljavajući procesu da se uvjeri o identitetu uključenog principala.

         Svaka Kerberos ulaznica sadrži skup zastavica koje se koriste za označavanje raznih atributa ulaznice. Mijenjanje većine zastavica može zatražiti klijent kad dobiva ulaznicu, dok se neke mijenjaju na zahtjev Kerberos poslužitelja ([26]).

         Ulaznica za uslugu važi maksimalno do isteka valjanosti ulaznice za dodjelu ulaznica (Ticket Granting Ticket, TGT), na osnovu koje je izdana. Izuzetak je obnovljiva ulaznica, koja može važiti jednako dugo kao i ulaznica za dodjelu ulaznice. Preporučno minimalno razdoblje trajanja ulaznice je 5 minuta, maksimalno 1 dan ([26]).

3.4.1       Početna (initial) ulaznica

         Svaka ulaznica koju Kerberos poslužitelj dodijeli koristeći inicijalnu razmjenu ulaznica (tj. nije bazirana na ulaznici za dobivanje ulaznica, nego je dobivena od autentifikacijskog poslužitelja) označena je kao početna. Obično se koristi za direktnu komunikaciju s uslugom. Time se daje mogućnost npr. poslužitelju za promjenu lozinki da zatraži od klijenta da pokaže ulaznicu dobivenu direktnom upotrebom klijentovog tajnog ključa, umjesto one dobivene koristeći ulaznicu za dodjelu ulaznica. Tako se sprečava da napadač dođe do slobodne radne stanice (tj. praznog mjesta) s koje je netko još uvijek prijavljen za rad i da promijeni lozinku korisniku koji trenutno nije na tom mjestu ([03]) koristeći se ulaznicom za dodjelu ulaznice. Svaka ulaznica dobivena preko ulaznice za dodjelu ulaznice (TGT) ne može biti inicijalna.

3.4.2       Ulaznica za dodjelu ulaznice (TGT)

Kad klijent želi koristiti više usluga, treba različite ulaznice za svaku. Da bi se izbjeglo spremanje tajnog ključa na duže vrijeme u memoriji radne stanice, korisnik odmah nakon uspješne prijave dobiva samo jednu ulaznicu, valjanu jedino za uslugu koju pruža Kerberos sam. Ta inicijalna (initial) ulaznica ([36]) se naziva ulaznicom za dodjelu ulaznice (TGT, Ticket Granting Ticket). Kadgod klijent želi neku uslugu, Kerberos poslužitelj mu šalje ulaznicu za željenu uslugu kriptiranu sjedničkim ključem poslanim u ulaznici za dodjelu ulaznice. Na taj način tajni ključ je potreban samo za inicijalu ulaznicu, te se kopija u radnoj stanici može uništiti odmah nakon dobivanja iste ([07]).

3.4.3       Obnovljiva (renewable) ulaznica

         Ulaznice označene kao ovakve imaju dva vremena istjeka valjanosti. Prvo je u bliskoj budućnosti, kao normalne ulaznice (vrijeme kad trenutnoj instanci ulaznice istječe valjanost), a drugo kasnije (maksimalno vrijeme obnovljivosti, maximum renewable lifetime). Obično istječe ranije, no ako se prezentira Kerberosu u sklopu zahtjeva za obnavljanjem prije nego istekne kraći period, dobiva se zamjenska ulaznica. Ta zamjenska ulaznica vrijedi dodatni vremenski period, zajedno s novim sjedničkim ključem (session key). Ulaznica se neće obnoviti preko drugog vremena isteka, tj. može se obnavljati sve dok se ne dođe do tog krajnjeg vremena. Kod svakog obnavljanja, Kerberos (točnije autentifikacijski poslužitelj) može konzultirati “vruću listu” (hot list) da provjeri je li ulaznica prijavljena kao ukradena od njene zadnje obnove. U tom slučaju odbit će ju obnoviti i time reducirati razdoblje valjnosti ukradene ulaznice ([26]).

         Prednost ovog mehanizma je u tome što vjerodajnice (credentials) mogu biti valjane duže vrijeme, no neće se obnoviti ulaznice koje su prijavljene kao ukradene. Time se sprečava njihova daljnja uporaba ([09]). Ukoliko bi se koristila dugovažeća ulaznica, bio bi to sigurnosni rizik. Napadač bi mogao iskoristiti ukradene ulaznice koje mu zbog svog dugog trajanja daju dovoljno vremena da izazove ozbiljnu štetu ili dođe do važnih/tajnih informacija. Ovakav kompromis je puno prihvatljiviji od dugovažećih ulaznica zbog barem dviju prednosti ([20]):

·         reduciran je vremenski interval valjanosti za ukradene ulaznice – ako napadač dođe do obnovljive ulaznice nakon što joj je isteklo maksimalno vrijeme obnovljivosti, beskorisna je

·         korisnik može obavijestiti Kerberos poslužitelj da mu ulaznica više ne treba, te će tako ulaznica izgubiti mogućnost obnavljanja

3.4.4       Postdatirana (postdated) ulaznica [4]

         Ovaj mehanizam sličan je obnovljivim ulaznicama, s tim što postdatirana ulaznica nije valjana sve dok ne prođe startno vrijeme (starting time, trenutak kad ulaznica postaje valjana). Klijent potvrđuje ulaznicu prezentirajući ju Kerberosu kao što je opisano za obnovljive (renewable) ulaznice.

         Ovaj je mehanizam vrlo koristan kad se želi dobiti ulaznica koja će se koristiti u nekom kasnijem periodu (npr. niz zadataka, batch jobs), te ulaznica mora biti valjana u trenutku obavljanja svakog posla. Kako je vrlo opasno čuvati valjane ulaznice u redu (queue), jer će dugo biti izložene mogućem napadaču, postdatirane ulaznice su dobar način za dobivanje ulaznica za obavljanje poslova kad zadatak dođe na red. U slučaju prijavljene krađe, ulaznica neće postati valjana.

3.4.5       Zamjenske (proxiable) ulaznica

         Ponekad principal mora dopustiti da usluga (service) izvede neku operaciju u njegovo ime. Principal joj dozvoljava da privremeno preuzme njegov identitet dodjeljujući usluzi potvrdu zamjene ili ovlaštenje (proxy), npr. daje se dozvola poslužitelju koji upravlja pisačem da pošalje na ispis neke korisnikove datoteke.

         Zamjenska ulaznica je ulaznica koja omogućuje da korisnik dobije ulaznicu za uslugu s drugačijom IP adresom od one u ulaznici za dodjelu ulaznica. Razlika u odnosu na prosljedive (forwardable) ulaznice je u tome što se ne može zamijeniti svoja ulaznica za dodjelu ulaznica drugom ulaznicom za dodjelu ulaznica. Zamjenski se mogu koristiti samo ulaznice za usluge, tj. prosljedive ulaznice omogućuju transfer kompletnog vlastitog identiteta, dok zamjenske omogućuju transfer samo određenih ulaznica.

         Da bi se otežala upotreba ukradenih vjerodajnica (credentials), Kerberos ulaznice su obično valjane samo ako su poslane s onih mrežnih adresa koje su uključene u ulaznicu (iako je moguće zatražiti ulaznicu bez specificirane mrežne adrese). Klijent koji želi dodijeliti zamjensku ulaznicu mora poslati zahtjev za novom ulaznicom koja važi samo za mrežnu adresu usluge kojoj će se dodijeliti ovlaštenje (proxy) ([26]).

3.4.6       Prosljediva (forwardable) ulaznica

         Prosljediva ulaznica je primjer zamjenske (proxy) ulaznice gdje se usluzi omogućuje kompletna upotreba klijentovog identiteta, npr. korisnik se prijavi za rad na udaljenom sustavu i želi da autentifikacija radi s tog sustava kao da je lokalna prijava.

         U ulaznici je enkodirana IP adresa klijenta, što koriste aplikacijski i Kerberos poslužitelji za verificiranje adrese klijenta. Kerberos 5 uvodi novost: za vrijeme dodjele ulaznice za dodjelu ulaznica (TGT) klijent može zatražiti da se ulaznica označi kao prosljediva. Ako Kerberos poslužitelj odluči poštovati ovaj zahtjev, postavlja se odgovarajuća zastavica u polju zastavica u ulaznici. Ako je ona postavljena, korisnik može iskoristiti ovu ulaznicu da zatraži novu ulaznicu, no s drugom IP adresom, tj. može iskoristiti trenutne vjerodajnice (credentials) da bi dobio vjerodajnice valjane za neko drugo računalo ([20]).

         Ova ulaznica omogućuje prosljeđivanje autentifikacije bez potrebe za ponovnim unošenjem lozinke.

3.4.7       Nevažeća (invalid) ulaznica [5]

         Aplikacijski poslužitelji moraju odbaciti nevažeće ulaznice (one kojima je postavljena zastavica INVALID). Postdatirane (postdated) se ulaznice obično izdaju u ovakvom obliku, te se nevažeće ulaznice moraju validirati kod Kerberos poslužitelja. On će to učiniti samo ako je njihovo startno vrijeme prošlo, tako da se ukradene postdatirane ulaznice kojima nije prošlo startno vrijeme mogu voditi kao trajno nevažeće (pomoću mehanizama “vruće liste” - hotlist).

3.5        Autentifikator (authenicator)

Kad Kerberos poslužitelj radi ulaznicu za klijenta, u nju stavlja i klijentov identitet. Usluga koja primi ulaznicu ima klijentov identitet. No netko može ulaznice ukrasti i ponovo upotrijebiti. Da bi to spriječio, klijent uz ulaznicu šalje autentifikator (authenicator).

Autentifikator je jednostavan mehanizam čija je namjena sprečavanje ponovne uporabe starih ulaznica (replay) koje bi netko mogao kopirati dok putuju mrežom ili ih pronaći na nekoj radnoj stanici. Sastoji se od više dijelova, između ostalog od principalskog identifikatora klijenta (client’s principal identifier), mrežne adrese i trenutnog vremena. Autentifikator se zapečati (sealed) sjedničkim ključem (session key), dobivenim od autentifikacijskog poslužitelja (AS). Usluga dekriptira autentifikator sjedničkim ključem kojeg je dobila u ulaznici. Ako principalski identifikator (tj. ime korisnika) iz autentifikatora odgovara onom iz ulaznice, ako je mrežna adresa (tj. ime klijenta) u autentifikatoru ista kao ona s koje je paket poslan, te ako je vrijeme u autentifikatoru unutar dozvoljenog vremenskog okna (obično nekoliko minuta), tad usluga prihvaća ulaznicu. Kako autentifikatori istječu unutar vrlo kratkog vremena, važno je da satovi budu sinkronizirani ([07]).

Ako je tajni ključ kompromitiran, bilo tko može nastupiti kao principal sve dok se tajni ključ (onaj u Kerberos bazi) ne promjeni i sve dotad izdane ulaznice isteknu. Ako je sjednički ključ kompromitiran, svatko može uspješno nastupiti kao principal sve dok prethodno izdane ulaznice ne postanu nevaljane ([07]).

3.6        Osnovne naredbe

Primarno sučelje sastoji se od tri osnovne korisničke naredbe i dvije osnovne subrutine (koje se koriste u kerberiziranim aplikacijama)([07]):

·         korisnička naredba kinit – traži korisnikovu lozinku, pribavlja ulaznicu za dodjelu ulaznice (TGT), uništava lozinku čim je pohranjena ulaznica za dodjelu ulaznice i pridruženi sjednički ključ

·         korisnička naredba klist – daje popis svih ulaznica dobivenih tijekom trenutne sjednice (session)

·         korisnička naredba kdestroy – uništava sve ulaznice

·         subrutina make_application_request() – služi da se dobiju ulaznice i sjednički ključ za imenovanu uslugu, da se pripremi autentifikator i vrati rezultat aplikaciji tijekom inicijalnog zahtjeva za uslugu

·         subrutina read_application_request() – koristi ju aplikacijski poslužitelj za provjeru prisutne ulaznice i autentifikatora, vraća identitet nađen u ulaznici i prosudbu o autentičnosti tog identiteta

Za administriranje se koriste naredbe:

·         kadmin – dodavanje principala u bazu ili promjena lozinke već postojećem (samo administrator)

·         kpasswd – za promjenu lozinki (korisnici)

3.7        Kerberos klijent

         Kerberos klijent je entitet koji dobiva ulaznicu za neku Kerberos uslugu. U principu bilo koji principal može biti klijent, ukoliko to nekom principalu administrator izričito ne zabrani ([20]).

3.8        Kerberos poslužitelj

         Kerberos poslužitelj se sastoji od autentifikacijskog poslužitelja (AS) i poslužitelja za dodjelu ulaznica za dodjelu ulaznica (TGS). On posjeduje kopiju svake lozinke povezanu sa svakim principalom, pa je zbog toga izuzetno važno da bude što zaštićeniji. Većina ih pohranjuje principale u bazi, pa se na njih odnosi i termin “Kerberos baza podataka”. Ta baza podataka pohranjuje ključeve izvedene iz korisničkih lozinki, ne lozinke.

         Zbog pouzdanosti moguće je imati rezervne Kerberos čvorove, koji se nazivaju pomoćnim (slave) poslužiteljima. Svi pomoćni poslužitelji ažuriraju svoje baze podataka iz one u glavnom čvoru. Tajni ključevi koji su zapisani u bazi utvrđeni su prije, te preneseni kroz kriptirani kanal.

         U većini implementacija postoji i administracijski poslužitelj koji omogućuje manipulaciju bazom podataka s udaljenosti.

         Računalo na kojem će biti smješten Kerberos poslužitelj ne zahtjeva neku posebnu računalnu snagu niti skupu opremu. Zbog sigurnosti ne bi se trebalo dopustiti da neka druga usluga radi na njemu ili da korisnici imaju mogućnost rada na tom stroju. Za taj zadatak poslužit će i računalo sa slabijim procesorom i manjih tvrdim diskom, no taj stroj mora biti vrlo pouzdan – ako je on kompromitiran, cijelo područje (realm) bit će kompromitirano. Ukoliko se računalo sruši, neće se moći korisiti niti jedna Kerberos usluga ako nije konfiguriran pomoćni poslužitelj. Gubitak baze podataka u kojoj su pohranjeni podaci čitavog područja zahtjeva ponovnu razmjenu osjetljivih podataka sa svima u tom području, pa je rezervna pohrana nužnost. Rezervnu kopiju treba tretirati kao i glavnu, jer sadrže isti materijal.

         U velikim sredinama, s velikim brojem korisnika i ograničenim brojem administratora, može se dogoditi da je program za prijavu za rad preuređen tako da registrira lozinke neregistriranih korisnika ukoliko su se regularno logirali na pouzdano radno računalo (trusted host). Jednostavnije rečeno, to računalo ih registrira kod Kerberos poslužitelja, tj. ubacuje ih u bazu. U malim sredinama može se zahtjevati da korisnik dođe osobno do administratora da ga ovaj registrira u bazi, no kod velikog broja korisnika to je vrlo nepraktično. Iako je zbog toga ova metoda vrlo praktična, također je vrlo riskantna. ([14])

3.9        Aplikacijski poslužitelj

         Ovaj se pojam općenito se odnosi na kerberiziranu aplikaciju od koje klijenti traže usluge koristeći Kerberos ulaznice za autentifikaciju.

3.10   Područje (realm)

         Područje (realm) je autentifikacijska domena, skup korisnika i poslužitelja registriranih od strane jednog autentifikacijskog poslužitelja. Dio je područja imena (namespace) korisnika. Njime se mogu autentificirati usluge (services) koje se oslanjaju na odvojeno administrirani autentifikacijski poslužitelj ili skup poslužitelja koji dijele istu bazu autentifikacijskih podataka za svoju autentifikaciju. Usluga (service) može prihvatiti vjerodajnice (credetials) izdane od autentifikacijskog poslužitelja samo za područje (realm) kojem pripada, no i korisnici i usluge mogu biti pripadnici više područja. Imena područja unutar mreže moraju biti jedinstvena ([07]).

         Područja se nazivaju kako god se želi. U praksi su imena područja obično DNS ime domene pridruženo računalu u novoj Kerberos domeni, pisano velikim slovima.

         Područja mogu biti nezavisna (independent) ili poluzavisna (semi-independent).

3.10.1  Nezavisna područja (independent realms) [6]

         Neki korisnici mogu poželjeti pristup uslugama koje pripadaju područjima u kojima oni nisu registrirani, a neke poslužitelji mogu biti voljni ponuditi usluge korisnicima iz drugih područja. Ovakvi zahtjevi traže mehanizam za autentifikaciju korisnika kroz područja.

         Ovaj mehanizam omogućen je suradnjom administratora dvaju uključenih područja. Kerberos poslužitelj svakog takvog područa klijent je Kerberos poslužitelja drugog područja i dijeli tajni ključ za međupodručnu (cross-realm) uslugu za dodjelu ulaznica. Usluga za dodjelu ulaznica registrira se kao principal u nekom drugom području prilikom razmjene međupodručnih ključeva (exchange of inter-realm keys) ([26]).

         Uzajamni klijentski odnos između Kerberos usluga dozvoljava klijentu jednog područja autentificiranje u drugom području iako se ne dijeli nikakva informacija između klijenta i usluge u drugom Kerberos području. Kad se koristi ulaznica za dodjelu ulaznice, udaljena usluga za dodjelu ulaznica koristi međupodručni ključ (koji se obično razlikuje od njenog normalnog ključa) za dekriptiranje ulaznice za dodjelu ulaznice. Koristeći međupodručni ključ za dekriptiranje, udaljeni poslužitelj za dodjelu ulaznica siguran je da je ulaznicu tom klijentu izdao njegov vlastiti poslužitelj za dodjelu ulaznica (registriran kod njega). Jednom kad se klijent autentificirao Kerberos poslužitelju u novom području, može zahtjevati ulaznice za usluge u njemu.

         Područje može komunicirati s drugim područjem ako dijele isti međupodručni ključ ili ako područje dijeli međupodručni ključ s nekim drugim područjem koje komunicira sa željenim udaljenim područjem (tranzitivnost). Ukoliko klijent od Kerberos poslužitelja zatraži ulaznicu za usluge u području s kojim taj Kerberos poslužitelj ne dijeli ključ, klijentu se izdaje ulaznica za područje najbliže traženom ([26]). Autentifikacijska staza (authentication path) je niz područja kroz koja se prolazilo tijekom komunikacije između dva odredišna područja.

         Primjer: korisnik iz prvog područja želi pristup poslužitelju u drugom području. Najprije se mora autentificirati u prvom području koristeći inicijalni autentifikacijski protokol. Nakon što je to uspješno obavljeno, korisnik može zahtjevati ulaznicu za drugo područje. Tu ulaznicu pokazuje Kerberosu u drugom području i on ga propušta, no ulaznice koje se u drugom području izdaju korisniku iz prvog imaju oznaku da je korisnik iz prvog područja, tj. ulaznica kaže da je korisnik autentificiran u prvom području. Klijent prezentira novu ulaznicu krajnoj usluzi koja odlučuje hoće li ju prihvatiti ili ne, bazirano na svojoj vlastitoj autorizacijskoj politici.

         U verziji 5 uvodi se tranzitivna međupodručna autentifikacija (transitive cross-realm authentication). Dotad je (verzija 4) svaki par područja morao dijeliti međupodručni tajni ključ. Za grupu od N područja to je bilo 2(N-1)2 tajni koje su se morale razmjeniti da bi se pokrile sve moguće međupodručne autentifikacijske staze. U tranzitivnoj međupodručnoj autentifikaciji se definira staza područja spojenih međupodručnim tajnama i ta se staza koristi da bi se “skakalo” između područja dok se ne dođe do vjerodajnica u željenom području ([20]).

3.10.2  Poluzavisna područja (semi-independent realms) [7]

         U projektu Athena na MIT-ju predviđen je i mehanizam za autentifikaciju usluga (services) nezavisnim grupama koje se nalaze izvan kruga institucije. Problem je u tome što te grupe moraju imati način autentifikacije korisnika lokalnim uslugama čak i kad njihova veza s fakultetskim resursima ne radi, no istovremeno ne mogu držati kopiju Kerberosa koji pripada krugu MIT-a (Athena područje) jer nema garancije da će biti sigurna. Umjesto toga, svaka nezavisna grupa ima svoje područje.

         Lokalni poslužitelji prihvaćaju autentifikaciju i jednog i drugog područja. Većina usluga na MIT-u pak prihvaća autentifikaciju samo iz Athena područja (MIT). Kad je veza sa sveučilišnom mrežom  u funkciji, korisnici nezavisne lokalne grupe autentificiraju se Kerberosu Athena područja, a zatim se autentificiraju Kerberosu lokalnog, nezavisnog područja. Na taj način korisnici samo jednom upisuju lozinku (kod prijave za Athena područje) za korištenje i lokalnih i fakultetskih usluga. Korisnici u krugu sveučilišta koji žele usluge iz lokalnog područja također mogu koristiti ovaj mehanizam.

         Ako veza između nezavisne lokalne grupe i sveučilišta ispadne iz funkcije, korisnici se autentificiraju direktno lokalnom Kerberosu i na taj način mogu koristiti lokalne usluge. Ova lokalna autentifikacija ne dozvoljava korištenje usluga koje se nalaze na sveučilištu, no kako je veza u kvaru, to ionako nema veze.

         Preporuka je bila da korisnici izaberu različite ključeve za lokalni i sveučilišni Kerberos, jer lokalni može biti puno lakše kompromitiran.

3.10.3  Hijerarhija područja

Text Box: Slika 1- Hijerarhija područja (realms) ([03])

         Hijerarhija područja (primjer prikazan na slici) implementirana je samo u verziji 5. Omogućuje lakšu međupodručnu komunikaciju. Na ovaj način broj izmjena ključeva reducira se s O(n2) za verziju 4 (svaki sa svakim dijeli ključ) na O(log(n)). Kad aplikacija želi kontaktirati poslužitelj u udaljenom području, “šeće” kroz stablo prema odredišnom području, kontaktirajući autentifikacijske poslužitelje i tražeći ulaznicu za dodjelu ulaznice za strano područje. Najčešće se dodjeljuje ulaznica za slijedeće područje u ispravnom smjeru. Ako je supostavljena prečica (shortcut link), daje se odmah ulaznica za to područje. Aplikacijski poslužitelj može pak odbaciti ulaznicu koja je prošla kroz nepouzdana (untrusted) podučja ([03]).

3.11   Značenje sata

Vrlo je važno za Kerberos sustave da sistemski satovi u računalima unutar područja (realm) budu sinkronizirani. Ukoliko je razlika među njima prevelika, posljedica je odbijanje poslužitelja da pruži zatraženu uslugu jer smatra da napadač pokušava uporabiti ulaznicu kojoj je istekao rok valjanosti. Administrator može odrediti kolika je maksimalna dozvoljena vremenska razlika, tj. vremensko okno (obično nekoliko minuta) uz koju će sustav raditi ispravno. Za sinkronizaciju se mogu iskoristiti posebni vremenski poslužitelji (timeservers) ili NTP (Network Time Protocol) ([07]). NTP je kriptografski ojačan protokol za vremenske usluge. Omogućuje velikim mrežama sinkronizaciju programskih satova uz pomoć nekoliko vrlo točnih satova ([24]). U verziji 5 sinkronizacija satova nije od presudnog značenja kao u verziji 4.

3.12   Autorizacija u Kerberosu [8]

         Glavna zadaća Kerberosa je autentifikacija, tako da se direktno ne bavi funkcijama autorizacije i obračunavanja (accounting), iako je u početku bio zamišljen da služi i za to ([07]). Za podršku ovih triju srodnih funkcija od strane drugih usluga, verzija 5 nudi mehanizam transmisije autorizacijskih informacija o korisničkim računima (zaštićenih od tajne promjene) kao dio ulaznice. Ta informacija ima oblik restrikcija (koje se nalaze u autorizacijskom polju podataka na ulazinici) u uporabi ulaznice, no enkodiranje svake restrikcije je definirano autorizacijskim ili obračunskim mehanizmom koji se upotrebljava, ne Kerberos protokolom.

         Kerberos autorizacijski model temeljen je na principu da svaka usluga najbolje zna tko bi smjeli biti njenu korisnici i koji oblik autorizacije je prikladan.

3.13   Može li se UNIX baza lozinki korisnika pretvoriti u Kerberos bazu? [9]

         Korisničke lozinke u UNIX sustavima obično se nalaze u datotekama /etc/passwd ili /etc/shadow i kriptirane su funkcijom bez inverza. Za pretvaranje u Kerberos bazu treba znati prave lozinke korisnika. Ključevi u Kerberos bazi rezultat su primjene druge funkcije na korisnikovu lozinku.

         Svatko bi se mogao upitati zašto se ne koristi ista funkcija i za jedno i za drugo. Odgovor je da se rezultat funkcije u Kerberosu koristi kao ključ za kriptiranje osjetljivih podataka koji se prenose između korisnika i Kerberos poslužitelja, umjesto da se od korisnika traži da sami unesu taj ključ. Korisničkom lozinkom i dobivanjem ključa iz nje bave se Kerberos klijenti, a ne Kerberos poslužitelj. Lozinka korisnika ne putuje mrežom te ju nitko neće na taj način saznati. Problem je ipak što napadač koji ne mora znati lozinku nego je dovoljno da zna ključ da bi se uspješno autentificirao kao korisnik. Zbog toga bi bilo jako loše ako bi se koristile predvidljive vrijednosti, npr. onaj sadržaj u bazama podataka s lozinkama korisnika računala prije konverzije. Kako svatko može vidjeti tu datoteku, ključ svakog korisnika bio bi de facto javno objavljen!.

         Rješenje postoji, no onako kako se intuitivno željelo. Treba postaviti registracijski mehanizam koji dobiva korisnikovu UNIX lozinku kad on pokrene neku aplikaciju, te ju uspoređuje s lozinkom spremljenom u datoteci na računalu na koje se korisnik prijavio. Ako se slažu, program registrira tu lozinku kod Kerberos poslužitelja.

         Problem koji se ovdje je nužnost autentificiranja registracijskog programa Kerberosu kao administratora da bi program mogao registrirati korisnikovu lozinku. Ukoliko se to ne dozvoljava, program mora biti u mogućnosti da se autentificira odvojenoj administratorskoj registracijskoj usluzi.

 

 

4         Kerberos protokol

         Kerberos je dizajniran na principu distribucije ključeva koji su razvili Needhan i Schroeder [10]. Ključ je baza autenifikacije, koristi se za enkripciju i dekripciju poruka. Time se eliminira  potreba za dokazivanjem posjedovanja osjetljivih informacija samim njihovim otkrivanjem. Da bi se neki subjekt autentificirao Kerberosu, jedna od dvije stvari se treba dogoditi ([20]):

1.       korisnik treba u nekom trenutku unijeti tajni podatak

2.       tajni podatak treba biti pohranjena negdje u računalu

Usluga za Kerberos V4 je dostupna na UDP portu 750. Za V5 usluga je dostupna na portu 88, a administracija na 749.

4.1        Kerberos baza podataka

Baza podataka unutar Kerberos poslužitelja ima slogove za svakog principala (svaki korisnik i usluga) poznatog unutar tog područja (realm). U bazi su pohranjene slijedeće informacije ([07]):

·         principalski identifikator (principal identifier), uključujući instancu identifikatora (instance identifier)

·         principalov tajni ključ (lozinka)

·         datum istjecanja

·         datum zadnje promjene sloga

·         identitet principala koji je zadnji mijenjao slog

·         maksimalno razdoblje valjanosti ulaznica (lifetime) koje se dodjeljuju dotičnom principalu

·         atributi

·         implementacijski podaci, nevidljivi izvana: verzija ključa (key version) i verzija glavnog ključa (master key version), te pokazivač na stare vrijednosti tog sloga; različiti ključevi mogu biti povezani s istim principalom, pa se svakom ključu pridružuje verzija

Tajni ključ mora ostati tajan. Ta se polja u bazi reverzno kriptiraju (reversibly encipher) glavnim ključem (master key) autentifikacijskog poslužitelja. Tako kriptirani ključevi mogu se mrežom poslati pomoćnim (slave) poslužiteljima, bez poduzimanja nekih rigoroznih mjera zaštite prijenosa. Glavni ključ ne sprema se u bazi, nego se njime upravlja odvojeno.

Autentifikacijski poslužitelj može sebe autentificirati alatima za rad s bazom (kao što je npr. kadmin) pomoću stash datoteke.

         Kerberos bazu podataka za neko područje nadopunjuje i njome upravlja jedan KDBM (Kerberos Database Management) poslužitelj. Autentifikacijske zahtjeve obrađuje jedan ili više KKDS  poslužitelja (Kerberos Key Distribution Server), svaki s identičnom kompletnom kopijom Kerberos baze. Kako svi KKDS poslužitelji imaju iste podatke, bilo koji od njih može obraditi bilo koji autentifikacijski zahtjev. Klijent može s liste KKDS poslužitelja odabrati onaj koji mu je najbliži u smislu topologije mreže. Razdioba odgovornosti između KDBM i KKDS poslužitelja ne znači da to moraju biti različita domaćinska računala (host) – svi mogu raditi i na samo jednom računalu. Svrha razdiobe je pojednostavljenje nadopunjavanja baze i poboljšanje performansi. Sve operacije KKDS poslužitelja u odnosu na bazu svode se na čitanje (read-only), a KDBM služi da bi oni primili nadopune za svoje kopije baze ([07]).

         Prilikom kopiranja baze iz KDBM u KKDS poslužitelje, koristi se Kerberos uzajamni (mutual) autentifikacijski protokol, te se razmjeni siguran enkripcijski ključ između KDBM i dotičnog KKDS poslužitelja. Podaci se prenose običnim FTP protokolom, no nikakve lozinke niti ikakvi osjetljivi podaci ne šalju se u čistom tekstu. Uporabom kontrolnog sumiranja (checksum) zapečaćenog (sealed) sjedničkim ključem kontrolira se integritet podataka. Integritet prenesenih podataka KKDS provjerava izračunavanjem kontrolne sume i usporedbom dobivene s poslanom. Ako se slažu, tek tada se njegova baza nadopunjuje.

Iako se spremaju samo osnovni podaci (bez brojeva telefona ili sl.), baza može biti prilično velika ukoliko je broj korisnika velik. Kerberos sučelje za upravljanje podacima u toj bazi može se upotrijebiti na dva načina ([07]):

1.       ručno, skupom alata s radne stanice administratora sustava (ako je broj korisnika u području malen)

2.       automatizirano, SMS sustavom (Service Management System) za veći broj korisnika

U oba slučaja održavanje se vrši preko mreže, koristeći autentificirane sigurne veze.

Dodavanje novog korisnika nije veliki problem ako se radi o malom broju novih korisnika. Jednostavno se traži da potencijalni korisnik dođe do administratora s dokumentima i administrator mu otvara korisnički račun. No ako je taj broj veći (npr. studenti koji su tek upisali prvu godinu na sveučilištu), tad je takvo rješenje vrlo neprikladno. SMS sustav nudi alternativno rješenje: automatiziranu prijavu.

Bit automatizirane prijave je da korisnik sam odabire principalski identifikator (principal identifier) i pridruženu lozinku bez uključivanja administratora sustava u taj postupak. SMS poslužitelj dobiva listu potencijalnih novih korisnika (novih studenata). Novi korisnik prijavljuje se radnoj stanici kao neautentificirani korisnik, te stupa u interakciju s registracijskim programom. Ta aplikacija uzima ime, identifikacijski broj, predloženi principalski identifikator i lozinku, te se spaja s SMS poslužiteljem i provjerava slažu li se dano ime i identifikacijski broj studenta (nešto pout PIN-a za bankomat karticu) s onim unesenim u listu. Ako se slažu, SMS daje sjednički ključ za dodavanje novog korisnika. Aplikacija otvara kriptiranu komunikacijsku vezu s Kerberos poslužiteljem da bi se dodao tog principala u bazu. Kerberos poslužitelj provjerava da li se dotični principal već nalazi u bazi korisnika. Ako ne, dodaje se i postupak uspješno završava ([07]).

Ovakav pristup ima i slabu stranu. Netko tko zna ime i studentski identifikacijski broj nekog novog studenta može se prijaviti kao taj student i raditi pod njegovim imenom. No sustav će registrirati pokušaj registriranja već registriranog principala te će odbaciti ponovnu registaciju. To može biti znak da je netko izvršio prevaru. Pravi korisnik tada se javlja administratoru koji može promijeniti lozinku u bazi ([07]).

Promjena lozinke moguća je samo uz početnu (initial) ulaznicu.

Baze za Kerberos verziju 4 i za verziju 5 se razlikuju, jer V5 korsti drugi algoritam stvaranja ključeva iz lozinki, no koncepcija baze i princip rada su isti. Verzija 5 može usluživati klijente verzije 4.

4.2        srvtab/keytab – autentifikacija poslužitelja

Kad se želi sustavu dodati nova kerberizirana aplikacija, administrator mora obaviti nekoliko radnji. Poslužitelj  najprije mora biti registriran u bazi i mora mu se dodijeliti privatni ključ, obično automatski generiran slučajan broj. Zatim se neki podaci (uključujući poslužiteljev ključ) kopiraju iz baze i stavljaju u datoteku na poslužiteljskom stroju. U Kerberos verziji 4 obično se stavaljaju u datoteku /etc/srvtab (service key file). Treba napomenuti da se taj ključ ne izvodi iz nikakve lozinke nego se radi o slučajno kreiranom ključu ([36]). Kerberos biblioteka koju poziva poslužitelj koristi informacije u toj datoteci da bi dekriptirala primljene poruke (kriptirane poslužiteljevim ključem). Ta datoteka autentificira poslužitelja kao što korisnika autentificira lozinka upisana za terminalom ([08]).

U Kerberos verziji 5 ova datoteka se naziva keytab (key table). Obično se nalazi u /usr/local/var/krb5kdc/.k5.<PODRUČJE>.

4.3        Komunikacijski protokol

Kerberos protokol može se okvirno svesti na nekoliko važnih elemenata. Klijent zahtjeva od autentifikacijskog poslužitelja (AS) vjerodajnice (credentials). AS odgovara šaljući ih kriptiranje klijentovim ključem. Vjerodajnice se sastoje od ulaznice za uslugu i privremenog enkripcijskog ključa (sjedničkog ključa). Klijent šalje ulaznicu (sa svojim identitetom i sjedničkim ključem) kriptiranu ključem poslužitelja od kojeg zahtjeva uslugu. Sjednički ključ, kojeg dijele klijent i poslužitelj, služi da se autentificira klijent, a po potrebi i poslužitelj. Može poslužiti i za enkripciju daljnje komunikacije ili razmjenu novih (podsjedničkih, subsession) ključeva za enkripciju komunikacije ([26]).

Sam protokol sastoji se od nekoliko podprotokola (ili razmjena). Dva su načina kojima klijent može zatražiti vjerodajnice od poslužitelja. Prvi način: klijent zahtjev za ulaznicom šalje u jasnom tekstu, a odgovor dobiva kriptiran svojim tajnim ključem. Ovako se obično traži ulaznica za dodjelu ulaznice (TGT). Drugi način: klijent šalje zahtjev poslužitelju za dodjelu ulaznica (TGS, Ticket Granting Server). Šalje mu ulaznicu za dodjelu ulaznica na isti način kako bi kontaktirao neki drugi poslužitelj koji traži Kerberos vjerodajnice. Poslužitelj za dodjelu ulaznica održava “vruću listu” (hotlist) ulaznica koje su poništene (cancelled), te se svaka ulaznica za dodjelu ulaznica koja dođe provjerava.

Na slici je prikazan klasičan Kerberos protokol dodjele ulaznice za uslugu. AS predstavlja autentifikacijski poslužitelj, a TGS poslužitelj za dodjelu ulaznica. Ta dva poslužitelja tvore Kerberos poslužitelj, te su združeni crtkanim pravokutnikom.

Poslužitelj za dodjelu ulaznica generira ulaznicu za željenu uslugu koristeći informacije dobivene iz ulaznice za dodjelu ulaznica i autentifikatora. U njoj se nalazi i sjednički ključ, kojim će se kriptirati daljnja komunikacija između dviju strana. Zbog toga korisnik ne mora više puta unositi svoju lozinku ([49]).

Text Box: Slika 2- shematski prikaz Kerberos protokola ([14])         Opis poruka (za Kerberos V5):[11]

m1 –  KRB_AS_REQ: u, tgs, RL, N

Korisnik[12] (u) zahtjeva ulaznicu za TGS poslužitelj (tgs). Klijent može specificirati brojne opcije u početnom zahtjevu, npr. da li da ulaznica bude obnovljiva, postdatirana itd. N predstavlja prigodnu jednokratnu oznaku (nonce), koja služi da klijent provjeri je li ulaznica dobivena u odgovoru svježa. Može biti neki slučajan broj ili generirana sistemskim satom, no važno je da se ne ponavlja, tj. ne upotrebljava višekratno. RL označava traženo razdobe valjanosti (requested lifetime).

U verziji 4: u, tgs, ts, L, gdje L označava razdoblje valjanosti (lifetime), a ts vremenski biljeg (timestamp).

m2 – KRB_AS_REP: u, {Kc,tgs, N, tstart, texp, tgs}Ku, {Tc,tgs}Ktgs

U odgovoru AS šalje sjednički ključ (Kc,tgs) kriptiran korisnikovim tajnim ključem (Ku) kojeg znaju samo AS i korisnik. Klijent (npr. radna stanica za kojom sjedi korisnik i unosi podatke) dobiva ulaznicu (Tc,tgs) kriptiranu tajnim ključem poslužitelja od kojeg se traži usluga  (u  ovom slučaju TGS, Ktgs).

Ulaznica za dodjelu ulaznica ima format: (c, u, tgs, tstart, texp, L, Kc,tgs), gdje je L razdoblje valjanosti (lifetime), tstart vrijeme kad ulaznica postaje valjana (startno vrijeme), a texp vrijeme kad postaje nevaljana. Klijentsko računalo (c) također je predstavljeno u ulaznici, i to svojom mrežnom adresom. Ukoliko klijent nije poslao svoje trenutno vrijeme u zahtjevu, poslužitelj umeće svoje trenutno vrijeme ([26]). U nekim slučajevima ne stavlja se trenutno vrijeme, nego vrijeme od kojeg će ulaznica važiti (npr. za odložene ulaznice). Oznaka {info}Kx znači da je informacija info kriptirana tajnim ključem Kx principala x, a Kx,y da je kriptirana sjedničkim ključem kojeg dijele principali x i y. Klijent dekriptira dobivenu poruku pomoću tajnog ključa, koji se izrađuje iz lozinke posebnim algoritmom. Treba primjetiti da lozinka ne putuje kroz mrežu, nego se ključ iz lozinke dobiva lokalno (izračunava ga klijent – radna stanica). Nakon dekriptiranja klijent posjeduje ulaznicu za željenu uslugu (TGS) i sjednički ključ, te se lokalna kopija lozinke i njegov tajni ključ (koji su u memoriji klijenta) uništavaju.

Autentifikacijski poslužitelj nezna da li je klijent onaj principal koji je imenovan u ulaznici, no to nije ni važno, jer samo imenovani principal posjeduje ključ za dekriptiranje ([26]).

U verziji 4 (V4) ova poruka bila je oblika: {Kc,tgs, ts, {c, u, tgs, ts, L, Kc,tgs}Ktgs}Ku. ts označava vremenski biljeg (timestamp). Ulaznica za dodjelu ulaznica Tc,tgs = (c, u, tgs, ts, L, Kc,tgs) bila je dvostruko kriptirana, te ju je klijent morao dekriptirati prije slanja poslužitelju. Ispuštanjem dvostrukog kriptiranja ulaznice dobiva se na performansama (pogotovo ako je enkripcija zahtjevna u smislu procesorskog vremena) bez značajnijeg povećanja rizika ([06]).

m3 – KRB_TGS_REQ: {A}Kc,tgs, {Tc,tgs}Ktgs, p, N’, RL

Klijent postavlja poslužitelju zahtjev za ulaznicom koja će mu omogućiti korištenje usluga poslužitelja p, šaljući ulaznicu za dodjelu ulaznica kriptiranu ključem poslužitelja za dodjelu ulaznica ({Tc,tgs}Ktgs) i autentifikator kriptiran sjedničkim ključem kojeg dijele TGS i klijent ({A}Kc,tgs). Autentifikator sadrži ime korisnika, klijentovu mrežnu adresu  (s koje se zahtjev šalje) i vremenski biljeg (trenutno vrijeme) koji igra važnu ulogu u protokolu. Odgovor mora stići u kratkom vremenu, zbog čega je važno da sistemski satovi budu sinkronizirani, tj. da razlika među njima ne bude velika. Kako satovi ne rade savršeno, postoji mala razlika između vremenskog biljega i sistemskog vremena (vrijeme utrošeno na putovanje se može zaboraviti – ostaje dakle razlika zbog neusklađenih satova i vremena potrebnog za dekripciju). U autentifikatoru može biti sadržan i podključ – subsession key (ako se želi pregovarati o njemu), te slučajan broj koji će biti početni u slijedu brojeva korištenih u nekim složenijim razmjenama poruka. N’ predstavlja novu oznaku.

U verziji 4 poruka je glasila: p, ts, {A}Kc,tgs, {Tc,tgs}Ktgs

m4 – KRB_TGS_REP: u, {Kc,p, N’, tstart’, texp’, p}Kc,tgs, {Tc,p}Kp

Poslužitelj za dodjelu ulaznica odgovara šaljući ulaznicu za željenu uslugu kriptiranu ključem poslužitelja koji daje tu uslugu ({Tc,p}Kp = {u, c, tgs, tstart, texp, L, Kc,p}Kp), te dajući sjednički ključ koji se poslužitelj p i klijent c koristiti za međusobnu komunikaciju ({Kc,p}Kc,tgs).

U verziji 4: {Kc,p, {Tc,p}Kp}Kc,tgs ; Tc,p = (u, c, tgs, ts, L, Kc,p)

m5 – KRB_AP_REQ: {A}Kc,p, {Tc,p}Kp

Klijent zahtjeva od poslužitelja uslugu šaljući mu svoj autentifikator kriptiran sjedničkim ključem ({A}Kc,p), do kojeg će poslužitelj doći kad dekriptira ulaznicu za željenu uslugu ({Tc,p}Kp), koja sadržava sjednički ključ, a kriptirana je njegovim tajnim ključem. Ulaznica za uslugu može se koristiti proizvoljan broj puta, sve dok ne istekne (postane nevaljana). U autentifikatoru se nalazi drugi vremenski biljeg, ne onaj iz m3, jer je važno da autentifikator bude što svježiji (zbog sprečavanja ponovne uporabe starih ulaznica).

m6 – KRB_AP_REP: {ts’}Kc,p (opcionalno)

Poslužitelj vraća poruku u kojoj se nalazi vremenski biljeg ts (timestamp) iz autentifikatora (iz m5). Slanje ove poruke je opcionalno, tako da poslužitelj može jednostavno pružiti uslugu bez slanja ovog odgovora. Pomoću ove poruke provodi se međukorisnička autentifikacija. U verziji 4, vremenski biljeg u poruci bio je vremenski biljeg klijenta uvećan za jedan. U verziji 5 to nije potrebno jer su poruke u toj verziji tako formatirane da je nemoguće prepravljati poruke bez znanja pripadnih ključeva ([26]).

U slučaju bilo kakve pogreške, kao odgovor na zahtjev vraća se poruka KRB_ERROR u jasnom tekstu (nekriptirana).

Ako se žele u procesu razmjene podataka koristiti zaštićene poruke, koriste se KRB_PRIV i KRB_SAFE poruke. Klijent zahtjeva korištenje KRB_SAFE poruke kad želi detektirati potencijalne modifikacije poruka koje se razmjenjuju, tj. želi zaštitu integriteta. Komunikacija “sigurnim” porukama (safe messages) odvija se između aplikacija  koje zahtjevaju autentifikaciju svake poruke, ne mareći da li je poruka razotkrivena ili ne. KRB_PRIV poruke pružaju tajnost (confidentiality) i zaštitu integiteta ([26]). Ovaj tip poruke, “privatne poruke” (private messages ), predstavlja najviši nivo zaštite. Svaka poruka je i autentificirana i kriptirana. Koriste se npr. za slanje lozinki preko mreže ([08]). Neke aplikacije (zapravo većina) zadovoljavaju se autentifikacijskim postupkom samo na početku. U daljnjoj komunikaciji smatraju da je principal autentificiran i vrši se normalna komunikacija, kao i u nekerberiziranoj verziji.

Ukoliko se želi usluga od nekog poslužitelja za koji se mora predočiti početna (initial) ticket, koristi se modificirani postupak koji se grubo može opisati kao skraćenje prethodno opisanog protokola. Početne ulaznice se zahtjevaju za npr. promjenu lozinki.

Text Box: Slika 3- razmjena početnih (initial) ulaznica ([14])         Klijent (c) je razmjenio poruke m1 i m2 s autentifikacijskim poslužiteljem (AS). Nije zatražio ulaznicu za poslužitelja za dodjelu ulaznica, nego za drugog verifikatora (verifier), označenog s v. Poruka m3 se sastoji od autentifikatora (ime klijenta, trenutno vrijeme i mrežna adresa klijenta), kriptiranog dobivenim sjedničkim ključem (Kc,v), i ulaznice za uslugu, kriptirane ključem poslužitelja. Poslužitelj (verifikator koji zahtjeva da se klijent autentificira) dekriptira ulaznicu i dobiva sjednički ključ za dekriptiranje autentifikatora. Ukoliko se ime i mrežna adresa klijenta navedeni u dobivenoj početnoj (initial) ulaznici slažu s onim pročitanim iz autentifikatora, te ako vremenski biljeg pokazuje da je ulaznica valjana, pruža se željena usluga.

         Ulaznice su u verziji 5 razdijeljene u dva dijela. Ime poslužitelja je u jasnom tekstu, jer neki poslužitelj s više identiteta (npr. međupodručni poslužitelj za dodjelu ulaznica) mora znati ime da mogao izabrati ispravan ključ. Ostatak ulaznice je kriptiran.

         Poslužitelj za dodjelu ulaznica (TGS) treba čuvati popis svih valjanih autentifikatora. Naime, prijašnji zahtjevi mogu sadržavati vremenske biljege koji ih čine još uvijek valjanim, te se zahtjevi koji dolaze uz već primljenu ulaznicu i autentifikator ignoriraju. Ulaznica se može korisiti sve dok ne istekne, a autentifikator čini ulaznicu valjanom.

4.3.1       Međukorisnička (user-to-user) autentifikacija

         Međukorisnička autentifikacija je poseban Kerberos (V5) aplikacijski protokol koji omogućuje korisnicima da udomljuju sigurne aplikacijske usluge na svojim stolnim računalima. Kad korisnik konfigurira svoje stolno računalo s dugovažećim srvtab (odn. keytab) ključem, postaje vrlo privlačna meta. Međukorisnička autentifikacija amogućuje pokretanje usluge bez držanja dugovažećeg ključa na disku. Umjesto toga se koristi kratkovažeći sjednički (session) ključ dobiven prilikom prijave.

         Jedan korisnik se ponaša kao poslužitelj, drugi kao klijent. Na zahtjev korisnika-klijenta korisnik-poslužitelj šalje Kerberosu svoju ulaznicu za dodjelu ulaznice (TGT), bez sjedničkog ključa. Korisnik-klijent od Kerberos poslužitelja dobiva vjerodajnice (credentials) kriptirane sjedničkim ključem obiju ulaznica za dodjelu ulaznice. Oba korisnika tad mogu dektiptirati nove sjedničke ključeve i utvrditi međusobne identitete. Prednost ovakvog pristupa je što korisnik-poslužitelj mogućoj krađi izlaže samo svoj kratkovažeći sjednički ključ dobiven na početku, dok prava tajna, lozinka, ostaje u njegovoj memoriji. Korisnici će u daljnjoj komunikaciji upotrebljavati novi, podsjednički (subsession) ključ.

U Kerberosu V4 korisnik-poslužitelj svoj će identitet dokazati tako što će vratiti vremenski biljeg (timestamp) iz zahtjeva kojeg mu je poslao korisnik, uvećan za jedan ([29]). U verziji 5 to nije potrebno jer su poruke u toj verziji tako formatirane da je nemoguće prepravljati poruke bez znanja pripadnih ključeva ([26]).

         Nedostatak ovakvog pristupa je nužnost osvježavanja poslužiteljeve ulaznice za dodjelu ulaznica da bi poslužitelj nastavio primati klijentove zahtjeve. Ovaj protokol inicijalno je bio dizajniran za autentificiranje X Window[13] sjednica, gdje poslužitelj obično radi na nesigurnom stolnom računalu.

4.4        ASN.1 notacija[14]

OSI (Open Systems Interconnection) je međunarodno standardizirana arhitektura koja opisuje međusobno povezivanje računala od fizičkog do aplikacijskog sloja. Ključ je apstrakcija: dizajneri mogu specificirati dio sustava bez razmišljanja kako je taj dio uistinu implementiran ili predstavljen. Objekti u višim slojevima definiraju se apstraktno i implementiraju uz pomoć objekata u nižim slojevima. Metoda koju OSI nudi za specificiranje apstraktnih objekata naziva se ASN.1 (Abstract Syntax Notation One). Skup pravila za predstavljanje objekata kao nizova nula i jedinica naziva se BER (Basic Encoding Rules). Podskup BER skupa, nazvan DER (Distinguished Encoding Rules), daje jednoznačno enkodiranje svakoj ASN.1 vrijednosti.

ASN.1 je fleksibilna notacija koja dozvoljava definiranje različitih apstraktnih tipova i vrijednosti, od jednostavnih do složenih. BER opisuje kako predstaviti vrijednosti svakog ASN.1 tipa kao string okteta.

Sve poruke koje se izmjenjuju u Kerberos protokolu opisane su pomoću ASN.1 notacije. Time se izbjegavaju problemi kod definiranja višeoktetnih vrijednosti (npr. slijed okteta) koji su bili prisutni u verziji 4 ([03]). Korištenjem ovakvog kodiranja, u poruku se prije kriptiranja uključuje identifikacija (određuje se tip). Zbog uključivanja informacije o duljini poruke, napadač ne može razbiti poruku i predočiti neku skraćenu verziju kao ispravno enkodiranu poruku ([17]).

4.5        Vremenski biljeg (timestamp) i važnost vremenskog okna

         Kerberos se oslanja na vremenske biljege kao jedno od sredstava kontrole. Pomoću vremenskih biljega može se odrediti da li je ulaznica valjana ili je predočena neka stara, ukradena ulaznica koju napadač pokušava iskoristiti. Vremenski biljeg ima i druge primjene uz ove. Jedna od njih je međukorisnička (user-to-user) autentifikacije. Da bi se spriječilo da napadači resetiraju svoje sistemske satove (da mogu nastaviti koristiti ulaznice koje su istekle tj. postale nevaljane), Kerberos poslužitelji odbacuju zahtjeve za ulaznicama onih računala čije se sistemsko vrijeme razlikuje više od dopuštenog maksimuma. Vremensko okno  je interval u koji mora pasti sistemsko vrijeme onoga tko zahtjeva ulaznice, odnosno maksimalna razlika sistemskih satova. Može biti fiksno (V4, 5 minuta) ili podesivo (V5). Slično, radna računala (hosts) su konfigurirana tako da odbacuju odgovore od Kerberos poslužitelja čije sistemsko vrijeme nije unutar njihovog vremenskog okna.

         U verziji 5 provedene su manje promjene. Zbog  modifikacija klijenti se više ne moraju oslanjati na poseban vanjski vremenski izvor za sinkronizaciju satova  kao uvjet bez kojeg ne mogu koristiti Kerberos usluge. Protokol omogućuje podešavanje satova u hodu. Aplikacijski poslužitelji i dalje moraju sinkronizirati satove, iako je na njih moguće primjeniti tehnike primjenjene na klijente (no to jednostavno još uvijek nije implementirano).

         Zahtjev da svi satovi u mreži moraju biti sinkronizirani može predstavljati značajan problem, naročito ako je veza spora. Sinkronizacija satova onemogućava uporabu starih ulaznica (replay) uključivanjem enkriptiranog vremenskog biljega. Kerberos V4 je bio vrlo osjetljiv na točnost satova upravo zbog toga. U verziji 5 je uveden challenge/response (C/R) protokol koji omogućuje korisnicima dobivanje ulaznica bez potrebe za sinkronizacijom satova. U takvom protokolu se nekome postavlja zahtjev (challenge) slanjem oznake (nonce), na koji ovaj mora odgovoriti (response) vraćajući tu oznaku kriptiranu. Uvođenje oznaka poboljšava protokol jer postaje manje ovisan o sinkronizaciji satova u sustavu.

         U zahtjevu za ulaznicom (tj. u KRB_AS/TGS_REQ) klijent šalje jednokratnu prigodnu oznaku (nonce) u jasnom tekstu, označenu s “n”. Nju poslužitelj vraća u odgovoru, ali kriptiranu. To je potvrda klijentu da je dobio svježu ulaznicu, tj. da je dobivena ulaznica odgovor na njegov zahtjev. Važno je da ta oznaka bude svježa, tj. da prije nije bila korištena, jer bi se višekratnim korištenjem neke oznake moglo dogoditi da se klijentu podvale stare vjerodajnice, a on to ne primjeti zbog podudaranja višestruko upotrebljenih oznaka ([24]). Klijent iskorištava vremenski biljeg (vrijeme stvaranja ulaznice) kriptiran zajedno s oznakom da podesi svoj sat. Treba primjetiti da se vrijeme putovanja kroz mrežu zanemaruje (jer se radi o LAN ili eventualno MAN mrežama, nikako WAN). Razlika se može zabilježiti da bi se kasnije mogla izvršiti korekcija vremena.

         Umjesto oznaka, u verziji 4 su se koristili vremenski biljezi, te je sinkonizacija satova u području bio conditio sine qua non. U verziji 5, uvođenjem oznaka umjesto biljega, taj zahtjev više nije toliko rigorozan, iako se za generiranje oznaka upotrebljava sistemski sat ([24]).

         U [28] je izložen zanimljiv prijedlog o uporabi oznaka (nonces) i temeljitoj modifikaciji Kerberos protokola. Na taj način eliminira se jedna poruka (umjesto pet poruka – ako se izostavi odgovor usluge –  izmjenjuju se četiri poruke).

4.6        Enkripcija

Enkripcija je proces transformiranja podataka u drugi oblik koji se ne može razumjeti bez primjene sekundarne transformacije. Transformacija se provodi uz uporabu enkripcijskog ključa na način da  sekundarnu transformaciju može izvršiti samo netko tko posjeduje odgovarajući dekripcijski ključ. Kriptosustavi mogu biti simetrični, zasnovani na jednom (tajnom) ključu koji služi ia enkripciju i dekripciju, ili asimetrični. U asimetričnim sustavima postoji par privatni/javni ključ. Javni ključ se svima objavljuje, dok privatni ostaje skriven ([03]). Ono što je kriptirano jednim ključem, može se dekriptirati samo drugim ključem, ne istim ključem kojim je kriptirano.

Kerberos protokoli opisani u dokumentima dizajnirani su za korištenje kriptouređaja koji kriptiraju tok (stream encryption ciphers). Oni mogu biti simulirani korištenjem uobičajenih blok metoda kriptiranja (poput DES-a) u sprezi s metodama ulančavanja blokova (block chaining) i kontrolnih suma (checksum). Enkripcija se koristi da bi se dokazao identitet mrežnih entiteta koji participiraju u izmjeni poruka. Kerberos poslužitelju se vjeruje u smislu zaštite tajnih ključeva i pouzdanosti njegovih tvrdnji o identitetu nekog principala. Znanje tajnog ključa se koristi za dokazivanje autentičnosti principala ([26]).

Polazna pretpostavka u protokolu je zaštićenost korištene enkripcije od kriptoanalize. U nekim je slučajevima poredak polja u kriptiranim porukama tako izabran da se minimiziraju efekti loše izabranih ključeva. Dobar izbor ključa vrlo je važan. Ukoliko se ključevi izvode iz lozinke, one moraju biti dobro izabrane da otežaju svoje pogađanje. Poželjno je da funkcija za pretvaranje stringa (lozinke) u ključ nema inverza te da mapiranje bude različito za različita područja. Ukoliko je korisnik registriran u više područja i upotrebljava istu lozinku, napadač koji kompromitira Kerberos poslužitelj u jednom području neće dobiti niti izvesti korisnikov ključ za drugo područje ([26]).

Sustavi korišteni za enkripciju mogu biti:

·         NULL – nikakva enkripcija nije korištena, ne dodaje se kontrolna suma (checksum)

·         DES (Data Encryption Standard) s CRC-32 kontrolnom sumom

·         DES u CBC načinu s MD4 kontrolnom sumom – informacija se kriptira DES algoritmom uz uporabu metode ulančavanja kriptiranih blokova (cipher block chaining mode)

·         DES u CBC načinu s MD5 kontrolnom sumom

         Ključ se dobiva iz lozinke. Posebna funkcija uzima lozinke u jasnom tekstu, propušta ih korz poseban jednosmjerni hash algoritam da bi se dobio ključ za željeni enkripcijski algoritam. U verziji 5 koristi se dodatak lozinci: lozinka i dodatak se spajaju i to se konvertira u ključ. Na taj način korisnik može imati iste lozinke za više područja, no ključevi neće biti isti. Kao dodatak se koristi cijelo ime principala, uključujući i domenu.

Jedinica za enkripciju u Kerberosu 5 je modularna. Može se izvaditi iz izvornog koda i takav kod tada ne podliježe strogim američkim zakonima o izvozu kriptotehnologije. Izvađena se jedinica može zamijeniti enkripcijskim modulom nekog drugog proizvođača.

Postoji inačica Kerberosa V4 pod nazivom Bones koja je potpuno funkcionalna, no za razliku od “normalnog” Kerberosa ne koristi enkripciju. Zbog američkih zakona o izvozu kriptotehnologije, prema kojima se sustav poput Kerberosa smatra oružjem, iz izvornog koda se moralo maknuti ne samo pozive kriptobiblioteka, nego bilo kakav trag koji bi upućivao na kriptografiju. Tek tada je bio dozvoljen izvoz koda izvan granica SAD-a i Kanade. Enkripcija se mogla umetnuti u izvorni kod (često naporan postupak) nakon što se došlo do izvornog koda okljaštrenog Kerberosa (Bones). Aplikacija “misli” da se radi o pravom Kerberosu (jer je podržan Kerberos API), no ova verzija ne nudi nikakvu sigurnost, nego je samo surogat u nedostatku pravog Kerberosa. Umetanjem enkripcije u tu okljaštrenu distribuciju, dobiven je eBones (encryption + Bones) ([36]).

4.7        Kerberos sklopovlje: sigurnosni (secure) koprocesor IBM 4785[15]

         U IBM-u je nedavno začet projekt kojem je cilj stvoriti sigurnosni (secure) koprocesor koji bi na sebe preuzeo manipuliranje osjetljivim/tajnim podacima. U njemu se pohranjuje glavni (master) ključ, on generira sjednički ključ, vrši preautentifikaciju, te kriptira ulaznice. Umjesto da autentifikacijski poslužitelj kriptira poruke i šalje ih klijentima, to se odvija preko koprocesora. Zahtjeva se uspostava sigurne veze između autentifikacijskog poslužitelja (AS) i poslužitelja s koprocesorom (to može biti dodatna kartica u nekom računalu). Poruka KRB_AS_REQ treba se promijeniti tako da autentifikacijski poslužitelj prosljeđuje koprocesoru podatke koje je dobio od klijenta, zajedno s tajnim ključevima klijenta i željenog poslužitelja. Ključevi se prenose do koprocesora ili računala s koprocesorom, a kriptirani su glavnim ključem. Koprocesor to može dekriptirati, saznati ključeve principala, te odgovoriti onako kako bi u klasičnom Kerberos protokolu odgovarao autentifikacijski poslužitelj, šaljući istu poruku. Na sličan način promjenjena je poruka KRB_TGS_REQ. Bit promjene je samo u tome da se komunikacija odvija preko koprocesora, a da njemu AS osjetljive podatke kriptirane glavnim ključem. Klijenti i poslužitelji ne primjećuju razliku.

         Ovakav pristup ima nekoliko prednosti, npr. sklopovski generator slučajnih brojeva daje bolje rezultate (u smislu veće entropije) nego programski, a kritični podaci (ključevi) ostaju sigurni čak i ako je računalo kompromitirano. Što se tiče brzine enkripcije, za DES enkripciju se navodi brzina od 20MB/s (okteti, ne bitovi). Radi se na implementaciji (ove vrzije Kerberosa), zasad samo za Linux sustave. Programska podrška za ovo sklopovlje je već razvijena.

4.8        Kerberiziranje

Kerberiziranje programa je proces dodavanja autentifikacijskih poziva i provjera u mrežnu aplikaciju koja se sastoji od klijentskog i poslužiteljskog dijela. U aplikaciju se umeću pozivi Kerberos biblioteka da bi se obavila autentifikacija prilikom početnog zahtjeva za uslugom.

Kerberiziranje uključuje prilagođavanje aplikacija da saznaju korisnikov identitet, provjere njegove vjerodajnice (koje trenutno ima), provjere da li je ulaznica za željenu uslugu prisutna. One zatim trebaju zatražiti ulaznice koristeći ulaznicu za dodjelu ulaznice i sjednički ključ ([36]).

Aplikacije koriste dvije osnovne subrutine za autentifikaciju ([07]):

·         subrutina make_application_request() – služi da se dobiju ulaznice i sjednički ključ za imenovanu uslugu, da se pripremi autentifikator i vrati rezultat aplikaciji tijekom inicijalnog zahtjeva za uslugu

·         subrutina read_application_request() – koristi ju aplikacijski poslužitelj za provjeru prisutne ulaznice i autentifikatora, vraća identitiet nađen u ulaznici i prosudbu o autentičnosti tog identiteta

         Novije implementacije Kerberosa nude GSS API (Generic Security Services Application Programmer Interface) sučelje. GSS API je standardno sigurnosno programsko sučelje neovisno o korištenim mehanizmima. Omogućuje programerima dizajniranje aplikacija i aplikacijskih protokola koji koriste različite autentifikacijske tehnologije, uključujući Kerberos. GSS API pak zbog svog generičkog autentifikacijskog sučelja ne podržava sve mogućnosti koje nudi Kerberos. Primjerice, međukorisnička (user-to-user) autentifikacija trenutno nije podržana ([14]).

4.9        Razlike između Kerberosa V4 i V5

Klijenti V4 mogu biti posluženi od poslužitelja V5, no treba imati na umu da je promijenjen i protokol i način stvaranja ključa i format kriptiranih ulaznica. U Kerberos distribuciju uključen je poseban daemon zvan krb524 (five-to-four), koji uslužuje klijente verzije 4.

Kratak popis najvažnijih promjena ([20]):

·         algoritam za stvaranje ključa koristi čitavo principalsko ime

·         u mrežnom protokolu svugdje se koristi ASN.1 notacija

·         dodana je podrška za prosljedive (forwardable), obnovljive (renewable) i postdatirane (postdatable) ulaznice

·         ulaznice mogu sadržavati višestruke IP adrese i adrese za različite tipove mrežnih protokola

·         koristi se generičko kripto-sučelje, tako da se mogu koristiti drugi algoritmi uz DES

·         autentifikatori više nisu osjetljivi na moguću ponovnu uporabu (replay)

·         podrška za tranzitivnu međupodručnu autentifikaciju  

U protokolu su promjenjene poruke koje sadržavaju ulaznice. U verziji 4 ulaznice su bile nepotrebno dvostruko kriptirane (i ključem poslužitelja koji pruža željenu uslugu i sjedničkim ključem kojeg dijele klijent i onaj tko dodjeljuje ulaznicu). Izostavljanjem dvostrukog kriptiranja ulaznice ne povećava se značajno opasnost, a dobiva se na performansama. U međukorisničkoj (user-to-user) autentifikaciji vrlo je izražena uloga vremenskog biljega u verziji 4 (koji se u odgovoru strani koja je zahtjevala autentifikaciju vraća uvećan za jedan), dok u verziji 5 vremenska oznaka u toj poruci ima drugačiju ulogu.

Verzija 4 je ovisna o enkripcijskom sustavu (samo DES) i IP protokolu (koriste se samo IP adrese), što ju čini neprikladnom za neka okruženja. Razdoblje valjanosti (lifetime) ulaznice (najviše 21 ¼ sati) je prekratko za neke aplikacije (npr. simulacije). Nije podržana hijerarhija područja (realms), zbog čega je potrebno izvršiti O(n2) izmjena ključeva za povezivanje n područja. Uvođenjem hijerarhije područja u verziji 5, broj potrebnih tajnih ključeva se smanjuje.

Verzija 5 dizajnirana je modularno, tako da se pojedini dijelovi mogu maknuti ili zamijeniti (npr. modul za enkripciju), podržava više mrežnih protokola. Ulaznice su podijeljene na dio u jasnom tekstu (ime poslužitelja) i kriptirani dio (ostatak). Dok u verziji 4 autentifikacijski poslužitelj (AS) nije mogao znati da li je korisnik unio ispravnu lozinku i prikladno autentificiran, u verziji 5 moguće je zahtjevati preautentifikaciju (pre-authentication), tako da AS zna da li je unesena ispravna lozinka.

Dok je ulaznica u V4 bila obilježena svojim razdobljem valjanosti (lifetime, L), u V5 je to zamijenjeno s vremenom početka valjanosti (tstart) i vremenom isteka valjanosti (texp). Na taj način dobiva se gotovo neograničeno razdoblje valjanosti ulaznice.

4.10   Ograničenja i nedostaci  Kerberosa

         Ograničenje je svojstvo koja nije onoliko općenito koliko bi moglo biti, dok je nedostatak nešto što može iskoristiti napadač da prevari autentifikacijske mehanizme. Neki problemi su posljedica dizajna Kerberosa, jer je on bio namjenjen korištenju u okviru projekta Athena na MIT-u. Primjerice, u okviru projekta razmatrane su jednostavnije prijetnje, kao što su prisluškivanje i lažno predstavljanje. Ako se neko računalo koristi i kao usmjerivač paketa (router), što u projektu Athena nije bilo predviđeno, modificiranje i uklanjanje paketa postaje ozbiljna prijetnja. Neki problemi su posljedica nedostataka u protokolu. U [17] je razrađena detaljna analiza tih problema. Evo nekoliko najvažnijih:

·         svaki program mora biti prilagođen za rad s Kerberosom – zbog dizajna Kerberosa, svaki program koji ga koristi mora biti redizajniran (kerberiziran)

·         Kerberos ne radi najbolje u višekorisničkim sustavima. Ulaznice se u originalnom Athena rješenju drže u /tmp direktoriju zbog teškoća oko dijeljenja podataka između različitih procesa na istom UNIX računalu, pa se one mogu kopirati ili ukrasti. Ako se osobe A i B prijave na istom računalu u isto vrijeme, ono će biti autentificirano za obje osobe, tako da su za prijavljivanje na Kerberos poslužitelj najprikladnije bile jednokorisničke radne stanice.[16] Evolucijom protokola ta se opasnost smanjila.

·         Kerberos traži siguran Kerberos server  – taj poslužitelj radi s bazom podataka s lozinkama, te treba biti namijenjen isključivo za tu svrhu i fizički zaštićen; ako je on kompromitiran, cijelo područje je kompromitirano

·         Kerberos pretpostavlja da je samo mreža nesigurna, ne i računala u toj mreži; no teško je u tipičnom računalnom sustavu pronaći sigurno mjesto za privremeno spremanje ključa

·         nema zaštite od modificiranog sistemske programske podrške (trojanskih konja) – korisnik ne može provjeriti da li je računalo nekompromitirano, tj. računalo ne autentificira sebe korisniku; korisnik ne može znati da li je neki napadač ili program nešto promijenio u konfiguraciji računala i programa na njemu

·         ako se korisnikova lozinka probije ili se otkrije na neki drugi način, prisluškivač može upotrijebiti tu lozinku za dekriptiranje drugih ulaznica i zloupotrebu usluga)

·         sjednički ključevi su osjetljivi, jer moraju biti slučajno generirani – ali to je teško postići, jer računalo generira pseudoslučajne brojeve upotrebljavajući razne algoritme. Rješenje je upotrijebiti posebne sklopovske uređaje ili se osloniti na izvore slučajnosti u sustavu (tipkovnica, pomak miša, pristupanuje disku, šumovi itd.)

         Na adresi http://www.cert.org mogu se pronaći mnoge obavijesti koje se tiču pogrešaka u Kerberos kodu. Ova se organizacija ne bavi pronalaženjem nedostataka u koncepciji ili protokolu, nego samo nudi obavijesti o uočenim pogreškama (i eventualno ispravke).

         Primjerice, 18. svibnja 2000. (http://www.cert.org/advisories/CA-2000-06.html) bila je objavljena vijest o opasnim pogreškama (buffer overflow) u nekim funkcijama u izvornom kodu, koje omogućuju napadaču preuzimanje administratorskih privilegija. Pogađa sve implementacije izvedene iz MIT verzije 4 i samo one dijelove verzije 5 koji obrađuju zahtjeve principala verzije 4 (jer se radi o funkcijama koje se koriste u V4 autentifikaciji). MIT je ponudio odgovarajuće zakrpe. Kao prva pomoć za V5 dovoljno je zabraniti V4 autentifikaciju (dok se ne pribavi zakrpa). KTH Kerberos (švedska verzija eBones distribucije) ne pati od ovog problema.

         9. lipnja 2000. CERT je u dokumentu CA-2000-11.html objavio da je Kerberos V4 (i V5 koji obrađuje V4 zahtjeve) osjetljiv na napade uskraćivanjem resursa (denial of service). To može rezultirati izdavanjem neispravnih ulaznica za sve principale, neprepoznavanjem principala ili rušenjem autentifikacijskog poslužitelja. Ipak, treba napomenuti da Kerberos nije bio razvijan s ciljem obrane od ovakvih napada, nego prvenstveno zbog obrane od prisluškivanja i lažnog predstavljanja.

         Unatoč svemu, Kerberos se pokazao kao izvrstan i fleksibilan sustav, koji dobro radi u raznim sredinama.

 

5         Kerberos, javni ključevi i World Wide Web

5.1        Javni ključevi u Kerberosu

         U kriptografiji s javnim ključevima (asimerični algoritmi) enkripcija i dekripcija provode se pomoću para ključeva, jednog koji je opće poznat (javni ključ) i drugog, privatnog ključa, poznatoj samo jednoj osobi. Poruka kriptirana javnim ključem može se dekriptirati samo privatnim ključem, ne javnim (vrijedi i obrnuto). Koristeći ovakav sustav eliminira se nužnost čuvanja tajnih podataka u središnjem poslužitelju (npr. tajni ključevi). Budući da se poruke kriptirane ovom metodom duže i kriptiraju i dekriptiraju od onih kriptiranim simetričnim algoritmima, performanse su kritične kad poslužitelj mora izvršiti veći broj autentifikacijskih operacija.

         Prilikom autentifikacija u sustavima s javnim ključem, pouzdani posrednici za autentificiranje klijenata su izdavači cerifikata (Certificate Authorities, CA). U klasičnim Kerberos sustavima, klijentu se dodjeljuju relativno kratkovaljane vjerodajnice (ulaznice). Kad se želi uspostaviti veza s nekim poslužiteljem, uvijek se mora kontaktirati Kerberos poslužitelj i predočiti mu ulaznicu za dodjelu ulaznice. Izdavači certifikata pak dodjeljuju dugovaljane vjerodajnice - certifikate (public key certificate). Onaj tko posjeduje takav certifikat (bilo klijent ili poslužitelj) može se autentificirati bilo kome, bez potrebe za uplitanjem izdavača certifikata u to. Prilikom povlačenja certifikata (kad postaju nevaljani), treba obavijestiti sve poslužitelje o tome. To se postiže tako da se od poslužitelja zahtjeva da provjere kod izdavača važi li certifikat ili povremenim slanjem liste nevaljanih certifikata (Certificate Revocation List) svim poslužiteljima (koji primaju certifikate tog izdavača).

         Postoji više prijedloga o ugradnji javnih ključeva u Kerberos protokol, no u svima osim jednog zadržava se središnji autentifikacijski poslužitelj. U njima Kerberos poslužitelj registrira javne ključeve koji se koriste samo za inicijalnu autentifikaciju (između Kerberosa i klijenta). Klijenti ne moraju generirati nove ključeve u slučaju kompromitiranja. Aplikacijski poslužitelji i dalje koriste konvencionalu kriptografiju sa simetričnim ključevima, pa moraju u takvim slučajevima generirati nove ključeve([05]). Prilikom kontaktiranja autentifikacijskog poslužitelja, klijent šalje svoj certifikat, a dobiva ulaznicu za dodjelu ulaznice ([27]). Postoji i implementacija kerberizirane usluge koja koristi PGP javne ključeve za korisnike projekta Athena ([38]).

         U prijedlogu opisanom u [05] zahtjeva se uporaba operacija s javnim ključevima svaki put kad se zatraži ulaznica za uslugu. Te su operacije raspodijeljene između klijenta i poslužitelja, ne koncentirane u Kerberos poslužitelju. Kerberos poslužitelj prestaje biti uska kost u grlu, jer se iz certifikata može saznati identitet i javni ključ onoga kome je certifikat izdan. Izdavač certifikata (CA) kriptira ga svojim privatnim ključem, tako da svatko tko je registriran kod tog izdavača ima izdavačev javni ključ kojim može dekriptirati sadržaj certifikata i saznati identitet vlasnika i njegov javni ključ (prema [38]). Nizanjem certifikata (slično kao u međupodručnoj autentifikaciji) omogućuje se principalu da provjeri certifikat koji je izdao neki drugi izdavač.

         Verzija Kerberos arhitekture s javnim ključevima čiji je protokol opisan ovdje implementirana je u okviru projekta elektroničkog plaćanja NetBill ([05]). Postoji i verzija, nazvana Yakasha, koja koristi RSA tehnologiju javnih ključeva ([45]).

         Yakasha uvodi minimalne promjene u Kerberos protokol, a održana je kompatibilnost s prethodnim verzijama Kerberosa. U prednosti je nad klasičnom shemom time što kompromitiranje autentifikacijskog poslužitelja i baze podataka ne znači da napadač može oponašati nekog principala, te nije moguće (ili je znatno otežano) izvršiti napad odabranim pojmovima (dictionary attack)[17]. No, usluge Yakasaha poslužitelja ograničene su samo na jedno područje, a sustav je još uvijek u fazi razvoja ([45]).

         Paket koji omogućuje korištenje javnih ključeva u Kerberosu dostupan je na (samo za SAD i Kanadu): http://gost.isi.edu/info/pk_init/. Radi se o verziji koja koristi javne ključeve samo prilikom komunikacije s autentifikacijskim poslužiteljem (inicijalna razmjena poruka), ne o verziji čiji je protokol opisan ovdje. Promjene unesene u klasični protokol su minimalne, unesene samo u razmjenu poruka između korisnika i autentifikacijskog poslužitelja. U samoj implementaciji Kerberosa predviđena je mogućnost ubacivanje ekstenzija. Korisnik šalje (u inicijalnom koraku) autentifikacijskom poslužitelju svoj certifikat, zasnovan na javnom ključu, koji ga provjerava i daje ulaznicu za dodjelu ulaznica. Ona je  kriptirana slučajnim ključem, ne dugovažećim ključem korisnika. Ovaj slučajni ključ se vraća kriptiran uz uporabu certifikata ([27]).

5.1.1       Protokol s javnim ključevima

         U predloženom novom protokolu potpuno se zaobilazi autentifikacijski poslužitelj. Klijent (C) komunicira izravno s aplikacijskim poslužiteljem (S) ([05]):

1)C®S  SCERT_REQ: S

Klijent zahtjeva poslužiteljev certifikat.

2)S®C  SCERT_REP: s-cert

Dobivanje poslužiteljevog certifikata. Klijent treba provjeriti da li je certifikat valjan i izdan od pouzdanog izdavača.

3)C®S  PKTGS_REQ: S, {Tauth, Krand, auth-data}PS

    auth-data = C, c-cert, [Krand, S, PS, Tauth]PC-1

TGS zahtjev zasnovan na javnom ključu. Nakon primljenog certifikata, klijent može zahtjevati ulaznicu za uslugu izravno od poslužitelja. Javnim ključem poslužitelja kriptirano je inicijalno autentifikacijsko vrijeme (Tauth), slučajni jednokratni simetrični ključ (Krand), te još neki autentifikacijski podaci (auth-data). To se polje sastoji od dijela koje sadrži ime i certifikat klijenta, u jasnom tekstu, te dijela koji je potpisan (signed) privatnim ključem klijenta. Sve osim poslužiteljevog identiteta je kriptirano. Kriptiranjem klijentovog identiteta sprečava se da potencijalni prisluškivači dođu do te informacije. U praksi se obično umjesto kriptiranja poruke javnim ključem provodi kriptiranje nekim slučajnim simetričnim tajnim ključem, koji se onda kriptira javnim ključem.

Uključivanje inicijalnog autentifikacijskog vremena, tj. vremena kad je ta poruka generirana, vrši se zbog zaštite. Kako klijent generira taj vremenski biljeg, poslužitelj uspoređuje vrijeme generiranja i vrijeme prijema ulaznice. Ako je razmak prevelik (ispad iz vremenskog okna), odbija se usluga. Na taj način onemogućuje se ponovna uporaba starih ulaznica.

Tajni ključ koji se šalje u zahtjevu (Krand) nije sjednički ključ, nego ga poslužitelj koristi da bi kriptirao odgovor koji sadrži ulaznicu za uslugu i sjednički ključ.

Iz klijentovog certifikata poslužitelj saznaje klijentov javni ključ.

4)S®C  PKTGS_REP: TC,S, {C, S, KC,S, Tauth}Krand

                 TC,S = S, {KC,S, C, Tauth}KS

TGS odgovor zasnovan na javnom ključu. Šalje se ulaznica (TC,S) kriptirana simetričnim ključem poznatim samo poslužitelju (KS). U odgovoru je uključen i sjednički ključ (KC,S). Kako se ključ Krand svaki put nanovo generira i koristi samo jednom, može se uporabiti i kao jednokratna prigodna oznaka (nonce).

5)C®S AP_REQ: TC,S, {C, vremenski_biljeg}KC,S

Odgovor aplikacijskog poslužitelja. Direktna autentifikacija između klijenta i poslužitelja je završena. Od ove točke sve se odvija kao u klasičnom Kerberos protokolu

U ovoj shemi podržana je uporaba prosljedivih (forwardable) i zamjenskih (proxiable) ulaznica.

Ukoliko poslužitelj ne podržava ovaj protokol, predviđena je uporaba središnjeg poslužitelja za dodjelu ulaznica:

1)C®TGS - SCERT_REQ: TGS

2)TGS®C - SCERT_REP: tgs-cert

3)C®TGS - PKTGS_REQ: TGS, {Tauth, Krand, auth-data}Ptgs

                 auth-data = C, c-cert, [Krand, TGS, Ptgs, Tauth]PC-1

4)TGS®C - PKTGS_REP: {C, TGS, Kc,tgs, Tauth}Krand, TGT

                 TGT = Tc,tgs = TGS, {Kc,tgs, C, Tauth}Ktgs

5)C®TGS - TGS_REQ: C, S, vremenski_biljeg_1, TGT, {autentifikator}Kc,tgs

6)TGS®C - TGS_REP: C, {KC,S, S, vremenski_biljeg_1}Kc,tgs, TC,S

                     TC,S = S, {KC,S, C, Tauth}Ks,tgs

7)C®S   - AP_REQ: TC,S, {C, vremenski_biljeg_2}KC,S

 

         Prva četiri koraka slična su već prije objašnjenim. Klijent traži ulaznicu za uslugu u obluku ulaznice za dodjelu ulaznica (TGT) od poslužitelja za dodjelu ulaznica (TGS). Koraci 5-7 identični su koracima klasičnog Kerberos protokola. Prema [05] protokol nije ništa zahtjevniji (u smislu računalnog vremena) od ostalih rješenja zasnovanih na javnim ključevima (poput SSL-a).

5.1.2       Prednosti Kerberosa s javnim ključevima nad SSL protokolom

         Glavne prednosti su ([05]):

·         SSL je protokol prijenosnog sloja (u ISO referentni model računalnih mreža) koji se koristi samo u kombinaciji klijenta i poslužitelja koji koriste TCP protokol, dok je Kerberos u višem, aplikacijskom sloju, neovisan o transportnom protokolu

·         SSL dozvoljava ponovnu uporabu sjedničkog ključa da se izbjegnu operacije s javnim ključevima prilikom uspostave svake veze, te se od poslužitelja zahtjeva da arhivira sjedničke ključeve. Kerberos sjedničke ključeve izmjenjuje u obliku čitljivom samo onome kome su namjenjeni (kriptirane ulaznice) i nema potrebe za održavanjem arhive ključeva

·         Kerberos ulaznice mogu poslužiti za kriptiranje poruka koje prolaze kroz nekoliko poslužitelja na putu prema cilju – to nije moguće kod SSL-a

·         mehanizmi za prosljedive (proxiable) ulaznice, ugrađeni u Kerberos, zahtjevali bi proširivanje postojećih SSL certifikata

         Intuitivno se postavlja pitanje koliki je granični broj certifikata po izdavaču tako da je brzina rada još uvijek zadovoljavajuća. Praksa je pokazala da tvrtke koje izrađuju certifikate mogu rukovati stotinama tisuća certifikata jednog izdavača (CA). U širem kontekstu, to znači da bi se lako mogla stvoriti Kerberos područja (realms) s milijunima principala. Uz munjevit razvoj Internet trgovine i potrebom za pouzdanim metodama zaštite i autentifikacije/autorizacije, Kerberos arhitektura s inkorporiranim javnim ključevima nameće se kao ozbiljan takmac postojećim metodama([05]).

5.2        Autentifikacija u WWW okolini[18]

         World Wide Web (WWW) se može opisati kao “globalni, interaktivni, dinamički, raspodijeljeni, informacijski sustav koji koristi Internet”. Baziran je na dokumentima pisanim u jeziku HTML, koji se Internetom prenose protokolom HTTP[19].

         Razvijeno je nekoliko metoda za autorizaciju i autentifikaciju preko WWW-a. Trenutno svi WWW poslužitelji podržavaju kontrolu pristupa filtriranjem IP adresa. Specificira se s kojih je adresa dozvoljen pristup određenim sadržajima, a s kojih zabranjen. Upute se zapisuju u .htaccess datoteke. WWW poslužitelj prima zahtjev, uzima IP adresu s koje je došao zahtjev i pregledava što je za tu adresu navedeno u .htaccess datoteci, nastavljajući u skladu s uputama. Ta se datoteka može nalaziti bilo gdje unutar stabla koje WWW poslužitelj pretražuje. Upute navedene u njoj valjane su u dubljim granama sve dok se ne naiđe na drugu .htaccess datoteku, koja potpuno zamjenjuje prethodnu. Ova vrlo jednostavna metoda ipak nije dovoljna ukoliko se želi pouzdana zaštita, jer se IP adrese mogu krivotvoriti, a ukoliko se upotrebljavaju lozinke, one se prenose u jasnom tekstu.

         Uz filtriranje IP adresa, spomenimo još i lokalne oblike prijave (local login forms, u sklopu aplikacije se unose ime i lozinka), SSL, centralne oblike prijave (central login form, poslužitelj kontrolira prijavu), javne ključeve (pomoću certifikata koji sadrže razne informacije) te dodatne priključke za preglednike (browser plug-ins).

         HTTP protokol omogućuje da se pridruži odgovarajući MIME tip podacima koji se šalju. Preglednici podržavaju velik broj MIME tipova (text, html, jpeg, gif itd), no imaju i mehanizme koji omogućuju da korisnik doda novi MIME tip i pridruži ga nekoj vanjskoj aplikaciji (što se ponekad implementira kao dodatni priključak - plugin - za preglednik). Ako se preglednik susretne s takvim tipom podataka, taj tok podataka se predaje vanjskoj aplikaciji, odnosno priključku. Sigurnosni priključci (security plugins) primaju vjerodajnice (credentials) te šalju originalne zahtjeve zajedno s vjerodajnicama poslužitelju. WWW poslužitelj autentificira klijenta, izvršava zadane autorizacijske zadatke i procesira zahtjev. Problem nastupa kad treba autentificirati stranicu koja sadrži ugrađene slike u sebi. Tad se priključak koristi za autentifikaciju početnog zahtjeva (za stranicom), a cookie s vrlo kratkim razdobljem valjanosti se koristi za autentificiranje dodatnih zahtjeva aktiviranih početnim zahtjevom (slike).

         Glavna prednost autentifikacije primjenom dodatnih priključaka za preglednik je u tome što se može nadovezati na već postojeća sigurnosna rješenja u nekoj mreži. Priključke je, nažalost, vrlo teško napraviti, jer moraju biti specifični za pojedine platforme. Kad se implementiraju, vrlo ih je lako instalirati i koristiti. Priključak se koristi samo kad se pristupa zaštićenim informacijama, inače se tok podataka ne mijenja za normalan pristup podacima na mreži.

         Od implemetacija zasnovanih na priključcima, značajniji su projekt “Minotaur” (Minotaur u daljnjem tekstu) i “Kerberized Local Plugin” (KLP). KLP koristi isti dizajn i infrastrukturu kao i Minotaur, a razlikuje se od njega u nekim detaljima u implementaciji.

5.2.1       Projekt “Minotaur” – kerberizacija WWW-a[20]

         Cilj projekta “Minotaur” bio je iskorištenje postojeće računalne infrastrukture na Carnegie Mellon sveučilištu za siguran i autentificiran pristup WWW-u.

         Pretpostavka je da svi korisnici ove usluge imaju Kerberos principal i lozinku, te da postoji Kerberos principal (KWeb) za svaki WWW poslužitelj koji ima ime računala (hostname) kao instancu. Autentifikacija je zasnovana na  Kerberos verziji 4.

         Najveći je problem bio pronaći rješenje koje će raditi i s Netscape Navigatorom i s MS Internet Explorerom. Tehnologija priključaka (plugin) i Java apleti omogućuju dovoljnu kontrolu nad preglednikom (browser), tako da je moguće preuzeti zahtjeve za zaštićenom stranicom.

          Kad se primi zahtjev za zaštićenom stranicom, oznakom (tag) “EMBED” šalje se poseban MIME tip, koji  aktivira priključak na klijentskom računalu. Priključak ponavlja zahtjev zajedno s ispravnim vjerodajnicama. Podaci se kriptiraju sjedničkim ključem i vraćaju poslužitelju, koji dektiptira ulaznicu za uslugu i tako sazna identitet klijenta i sjednički ključ. Sjedničkim ključem poslužitelj dekriptira ostatak podataka. Za razmjenu podataka koristi se funkcija NPN_PostURL (na Netscape poslužiteljima) ili cookie. Kad je potvrđena dozvola za pristup, dokument se izravno šalje pregledniku. Sigurnost podataka osigurava SSL. Kao to izgleda u stvarnosti, može se vidjeti na https://web2.andrew.cmu.edu/test.html.

Slika 4-projekt Minotaur: pristupanje informaciji (HTTP GET zahtjev) ([39])

        

         Kao što slika prikazuje, nakon normalnog zahtjeva preglednika za zaštićenom informacijom (1), poslužitelj šalje MIME tip (ili HTML stranicu s oznakom EMBED) koji aktivira priključak (2). Priključak zahtjeva ulaznicu za KWeb uslugu i šalje autentifikator zajedno s URL adresom i eventualno nekim drugim podacima (ako je postavljen POST zahtjev), kriptirane sjedničkim ključem.

         Primjer stranice s ugrađenom EMBED oznakom:

<HTML> <h2>Doing KWeb Authenication .... </h2>

<EMBED type="application/x-kweb-plugin" mytime="unix-time-in-sec."

lifetime="cookies-lifetime" method="reload" | "submit" | "click"

server="a-full-hostname" realm="principal.instances@realm"

url="requested-url" signme="to-be-signed-data">

         Za slanje informacija od priključka do poslužitelja zadužena je Netscape funkcija NPN_PostURL ili cookie. Kad WWW poslužitelj primi zahtjev, poziva rutinu za autentifikaciju (Authentication Handler Routine). Ona dekriptira autentifikator (da ustanovi identitet korisnika) i sjedničkim ključem dekriptira ostatak podataka. Rutina za provjeru pristupa (Access Handler Routine) provjerava da li korisnik smije dobiti tu informaciju. Ukoliko smije, pribavlja stranicu. Kad je informacija spremna za slanje, rutina za odgovaranje (Response Handler Routine) se poziva i ona šalje dokument pregledniku.

         Opisana metoda se ne može primjeniti kad su rezultati GET zahtjeva objekti ugrađeni u stranicu (slike, animacije itd.). Da bi se zaštita proširila i na te objekte, poslužitelj šalje natrag klijentu autentifikator i kriptirane podatke koje je primio u obliku cookiea s vrlo kratkim razdobljem valjanosti. Preglednik će u budućim zahtjevima uključiti i kopiju cookiea. Cookie sadrži kriptirani vremenski biljeg koji pokazuje njegovu starost. Poslužitelj na taj način može biti konfiguriran da prihvaća cookie s različitim duljinama valjanosti za različite objekte (npr. cookie za slike mora važiti dulje od cookiea za tekst).

         Slanje informacija preko forme (HTTP POST zahtjev) nešto je teže od obrade GET zahtjeva, jer se mora ustanoviti i identitet korisnika koji šalje podatke i uvjeriti se da je to isti korisnik koji je postavio zahtjev za formom (form). U formu se (prilikom slanja poslužitelju) dodaje polje kriptirano sjedničkim ključem, a sadrži identitet korisnika.

         Za izgradnju sustava baziranog na Minotauru, korisnici trebaju priključak za preglednik, KWeb priključak (za poslužitelj) i Kerberos infrastrukturu. Trenutno je podržan Netscape poslužitelj, a od preglednika Netscape i MS Internet Explorer.

         Da bi se izbjegli problemi oko razvoja priključka za svaki preglednik i svaku platformu posebno, tim okupljen oko projekta planira razviti Java aplet, koji bi radio isto što i priključak.

5.2.2       Apache WWW poslužitelj i Kerberos[21]

         Za trenutno najpopularniji WWW poslužitelj razvijen je modul (mod_auth_kerb) koji omogućuje Kerberos V4/V5 korisniku autentifikaciju Apache WWW poslužitelju. Poslužitelj uzima korisničko ime i lozinku (Basic Auth metoda), te ih provjerava kod nadležnog Kerberos poslužitelja. Modul podržava i uzajamnu autentifikaciju, no većina preglednika to ne podržava (osim kerberiziranog Mosaica – KMosaic). Kako se korisničko ime i lozinka šalju u jasnom tekstu, preporučuje se korištenje SSL modula ili Apache-SSL poslužitelja za zaštitu tajnosti.

         Razvijen je i modul koji omogućuje autentifikaciju pomoću PAM sustava, te je na taj način moguće indirektno povezati Kerberos i WWW poslužitelj (http://blank.pages.de/pam/mod_auth_pam/ dist/mod_auth_pam.tar.gz).

 

6         PAM – autentifikacija pomoću zamjenjivih modula

6.1        Što je PAM?

         Ideja o PAM-u, fleksibilnom i transparentnom ([12]) mehanizmu za autentifikaciju korisnika, potekla je iz Suna. Poticaj je bilo to što je svaki put kad bi se razvio neki novi sustav za autentifikaciju trebalo prilagođavati postojeće aplikacije (ftpd, login itd.) da bi one podržale novu shemu. PAM (Pluggable Authentication Module) je skup dijeljenih biblioteka koje omogućuju administratoru da izabere kako će aplikacije autentificirati korisnike. Način autentifikacije i moduli za autentificiranje izabiru se preko konfiguracijske datoteka (pam.conf). Bit PAM-a je odvajanje procesa razvoja aplikacija koje koriste autentifikacijske mehanizme od razvoja samih shema. Korištenjem PAM biblioteka programi se mogu razvijati neovisno o shemi autentifikacije, a autentifikacijski moduli se povezuju s njima tijekom izvođenja (run-time). Moguće je mijenjati autentifikacijske mehanizme koji se koriste ili nadograditi postojeće mehanizme bez potrebe za mijenjanjem aplikacija.

         Aplikacijama je za autentifikaciju na raspolaganju PAM aplikacijsko programsko sučelje (API). Da bi aplikacija koristila PAM, u njezinom izvornom kodu moraju se eksplicitno pozivati PAM funkcije. To zahtjeva promjene u izvornom kodu, kao i kod kerberizacije ili prilagođavanja nekoj drugoj autnetifikacijskoj shemi, no prilagođavanje PAM-u je jednostavnije i nakon toga više nije važno koja se autentifikacijska shema koristi. PAM funkcije rade na “višem” nivou, tako da razvijatelj aplikacije ne mora brinuti o detaljima autentifikacije nakon ubacivanja poziva PAM funkcija u kod. Administrator naknadno određuje hoće li se koristiti Kerberos shema (pam_krb4) ili simple trust shema (pam_permit) ili nešto treće.

         Obično se PAM povezuje s Linuxom (Linux-PAM), no PAM nije koncepcija vezana samo za Linux. Postoje verzije za Solaris, SunOS, FreeBSD i HP-UX 9.0.

Text Box: Slika 5- osnovna arhitektura PAM-a (prema [16])         Središnje komponente PAM strukture su API autentifikacijke biblioteke (front-end) i moduli s mehanizmima specifičnim za autentifikaciju (back-end).

Slika prikazuje odnos između aplikacije, PAM biblioteke i modula. Kad aplikacija poziva PAM API, učitava se odgovarajući modul onako kako je utvrđeno u konfiguracijskoj datoteci.

 

 

 

 

6.2        Sudionici u autentifikacijskom procesu

PAM rezervira neke pojmove za specifikaciju jedinstvenih entiteta u procesu autentifikacije ([23]):

·         applicant-(aplikant) entitet (korisnik) koji pokreće aplikaciju zbog usluge

·         arbitrator-(arbitrator) entitet (korisnik) pod čijim identitetom aplikcija pregovara i uz čiju se dozvolu dodjeljuje usluga

·         user-(korisnik) entitet čiji se identitet autentificira

·         server-(poslužitelj) aplikacija koja daje uslugu, u potpunosti odgovorna za poslužiteljski kraj transportnog sloja koji povezuje poslužitelj s klijentom

·         client-(klijent) aplikacija koja daje sučelje aplikantu

·         module-(modul) autentifikacijska binarna datoteka koja daje podršku s poslužiteljske strane za neku autentifikacijsku metodu

·         agent-(agent) autentifikacijska binarna datoteka koja daje podršku s klijentske strane za neku autentifikacijsku metodu

Text Box: Slika 6- odnos sudionika u procesu (prema [23])Crte bez strelica označavaju interakcije u oba smjera, dok one sa strelicom označavaju opcionalne veze između modula (agent) i poslužitelja (applicant).

 

 

 

 

6.3        Linux-PAM

         Fleksibilnost PAM-a je u tome što dozvoljava administratoru izbor autentifikacijske sheme za sve ili bilo koju aplikaciju koja je napisana tako da koristi PAM. Implementacija na Linuxu nazvana je Linux-PAM i može poslužiti kao općeniti primjer PAM sustava.

         Linux-PAM pokriva 4 odvojena tipa upravljačkih zadataka: upravljanje autentifikacijom (authetication management), upravljanje korisničkim računom (account management), upravljanje sjednicom (session management) i upravljanje lozinkom (password managemet). Povezivanje željene sheme s ponašanjem aplikacije obavlja se kroz unose u odgovarajućim konfiguracijskim datotekama. Funkcije upravljanja (management functions) obavljaju moduli (modules) navedeni u konfiguracijskim datotekama. PAM biblioteka dinamički učitava lokalno konfigurirane module koji izvode autentifikacijske zadaće.

Text Box: Slika 7- organizacija Linux-PAM-a (prema [11])Lijevo je predstavljena aplikacija X. Ta se aplikacija sučeljava s Linux-PAM bibliotekom ne znajući ništa o tome za koju je autentifikacijsku metodu ona konfigurirana. Biblioteka ispituje sadržaj PAM konfiguracijske datoteke i učitava module prikladne za aplikaciju X. Ti su moduli iz jedne od četiri navedene grupe (sredina dolje) i poredani su (stacked) u poretku u kojem se pojavljuju u konfiguracijskoj datoteci. Kad ove module pozove Linux-PAM, oni izvršavaju različite autentifikacijske zadatke za aplikaciju. Tekstualne informacije, ponuđene korisniku ili zahtjevane od njega, mogu se izmjenjivati preko konverzacijske funkcije koju daje (provides) aplikacija. Služi za direktnu komunikaciju učitanog modula i aplikacije. Korisnik lozinku unosi samo jednom, prilikom prijave na sustav (single sign-on).

         Dobre strane PAM-a mogu se ilustrirati s više primjera. Uzmimo jedan ([11]): poslužitelj kojem je operacijski sustav Linux, a nudi više različitih usluga (WWW poslužitelj s područjima koja su ograničena kontrolom lozinki). Uporabom modula, PAM omogućuje aplikaciji pretraživanje nekoliko različitih baza podataka lozinki, čak i ako program nije eksplicitno kodiran za određenu bazu. To uključuje NIS baze lozinki (Sun Microsystems), NCP (Novell) te Linux ili Windows NT baze lozinki. Primjerice, korisnici u uredu ili odjelu se registriraju s korisničkim imenom i lozinkom na Novell ili NT lokalnu mrežu (LAN). PAM se može iskoristiti da ih se autentificira kad žele pristupiti nekim uslugama na Linux poslužitelju (npr. pristup određenom direktoriju kojem je pristup ograničen lozinkom). Pritom se ne moraju održavati odvojene baze lozinki za Linux i LAN poslužitelj, nego se PAM-u prepušta pretraživanje Novell ili NT baze.

6.4        Konfiguracija Linux-PAM-a[22]

Lokalna konfiguracija Linux-PAM-a nalazi se ili u datoteci /etc/pam.conf ili u direktoriju /etc/pam.d/. U novijim Linux sustavima konifuracijske datoteke se uglavnom nalaze u /etc/pam.d/ direktoriju dok se /etc/pam.conf koristi za usklađivanje sustava.

Općenita konfiguracijska linija u datoteci /etc/pam.conf sastoji se od pet tokena, odvojenih prazninama: imena usluge (service-name), tipa modula (module-type), kontrolne zastavice (control-flag), staze do modula (module-path) i argumenata (arguments). Pod imenom usluge misli se na uslugu povezanu s ovim unosom (ftpd, rlogind itd.). Postoji i specijalno ime (OTHER), rezervirano za usluge koje nisu navedene u popisu. Moduli spadaju u jedan od slijedeća četiri tipa:

·         auth: autentifikacija korisnika, ustanovljuje se da li je korisnik ono što tvrdi (upućuje aplikaciju da traži lozinku ili neki drugi vid identifikacije) i dodjeljuje privilegije preko svojih svojstava za dodjelu vjerodajnica (credentials). Vjerodajnica je nešto što korisnik posjeduje.To može biti Kerberos ulaznica, PAM ulaznica u obliku varijabli okoline (environment variables). UID i GID se ne smatraju PAM vjerodajnicama, nego se nazivaju user-credentials i za njihovu direktnu dodjelu se brine aplikacija ([12])

·         account: upravljanje korisničkim računom (account management) koje nije bazirano na autentifikaciji, obično za dozvoljavanje/uskraćivanje usluga u ovisnosti o dobu dana, dostupnim sistemskim resursima (maksimalan broj korisnika) ili o lokaciji korisnika

·         session: ovaj modul povezan je sa stvarima koje trebaju biti obavljene za korisnika prije ili poslije nego ih se da usluzi (mountanje direktorija, upis podataka u kontrolnu (log) datoteku itd.)

·         password: za osvježavanje (update) autentifikacijskog tokena povezanog s korisnikom

Kontrolna zastavica određuje kako PAM biblioteka treba reagirati na uspjeh ili neuspjeh modula s kojim je povezana. Moduli mogu biti nanizani (stacked), tj. moduli istog tipa  se izvršavaju u nizu, jedan za drugim, pa zastavica određuje relativnu važnost svakog modula. Sposobnost nizanja autentifikacijskih modula može se iskoristiti da se  integrira npr. login (proces za prijavu rada) s različiti autentifikacijskim mehanizmima ko što su RSA i Kerberos. Na taj se način ujedinjuju mehanizmi prijave i podržavaju se višestruki autentifikacijski mehanizmi.

Text Box: Slika 8- nizanje (stacking) u PAM-u ([16])Kad se uputi poziv preko progrmaskog sučelja (API), pozivaju se moduli u onom redoslijedu kako su navedeni. U slučaju predstavljenom na slici, korisnik se autentificira UNIX, Kerberos i RSA mehanizmima. U kontrolnoj datoteci (preko kontrolne zastavice) se može zatražiti da korisnik bude autentificiran i UNIX i Kerberos mehanizmima da bi mu se dozvolila prijava za rad. RSA se može proglasiti opcionalnim (tj. autentifikacija može biti neuspješna ovim mehanizmom a da se ipak dozvoli prijava) ([16]):

login auth required pam_unix.so

login auth required pam_kerb.so

login auth optional pam_rsa.so

Zbog nižućih (stacking) mogućnosti, nužno je da PAM API ne vraća nikakve podatke nego samo status, koji se vraća onome tko je uputio poziv. Zbog toga aplikacija može biti nezavisna  od modula.

Pod stazom do modula se podrazumjeva staza (s imenom) objekta koji se dinamički učitava.

 Argumenti su lista tokena koji se prosljeđuju modulu kad je pozvan, slično kao kod naredbe ljuske.

Autentifikacijski token je općenito lozinka, no ne mora nužno biti lozinka.

Fleksibilniji način konfiguracije je preko sadržaja direktorija /etc/pam.d/. U direktoriju se nalaze datoteke čije je ime isto kao ime usluge. To su konfiguracijske datoteke za imenovanu uslugu. Datoteke sadrže sva polja kao i pam.conf, osim polja s imenom usluge (jer je određeno imenom). Sve što je opisano za datoteku pam.conf vrijedi za pojedinačne konfiguracijske datoteke usluga.

Primjer standardnog UNIX pristupa (pam.conf):

OTHER auth required /usr/lib/pam_unix_auth.so

OTHER auth required /usr/lib/pam_unix_acct.so

OTHER auth required /usr/lib/pam_unix_passwd.so

OTHER auth required /usr/lib/pam_unix_session.so

PAM je vrlo fleksibilan mehanizam. Nivoi zaštite mogu varirati između nikakve i zabrane pristupa svakome. Treba pripaziti da se ne unište konfiguracijske datoteke, jer u tom slučaju se neće moći koristiti nikakve usluge sustava, tj. sustav će biti nedostupan svima. Poslužitelj se u tom slučaju treba podignuti u jednokorisničkom načinu i obnoviti konfiguracijske datoteka pomoću pohranjenih kopija ili napisati nove.

6.5        PAM moduli[23]

Linux-PAM modul je izvršna binarna datoteka koju dinamički učitava Linux-PAM biblioteka, konfigurirana pomoću datoteke pam.conf. Moduli se mogu alternativno statički povezati u Linux-PAM biblioteku. Aplikacija poziva Linux-PAM sučelje koje ima zadaću pronaći, učitati i pozvati prikladne funkcije u modulu. Funkcije modula su grupirane u četiri nezavisne upravljačke grupe (authentication, account, session i password) opisane prije u tekstu. Da bi bio odgovarajuće definiran, modul mora definirati sve funkcije unutar barem jedne od ovih grupa. Modul može sadržavati potrebne funkcije za sve četiri grupe.

6.6        Kerberos moduli

Ime Kerberos 4 modula je pam_krb4. Pokriva grupe authentication, password i session. Omogućuje dobivanje ulaznice za dodjelu ulaznice (TGT), uništvanje ulaznica prilikom odjave (logout) i promjenu Kerberos lozinke. Ovaj modul dolazi u svakoj distribuciji PAM-a.

Kerberos 5 modul dolazi zapravo u tri modula, od kojih svaki pokriva jednu od tri grupe. To su: pam_krb5_auth – autentifikacijski modul, pam_krb5_sess – sjednički modul, te pam_krb5_passwd – modul za rad s lozinkama. Dostupno na: http://www-personal.engin.umich.edu/~itoi/ pam_krb5/pam_krb5-6.1-1.tar.gz.

Razvijen je i modul za Apache WWW poslužitelj koji omogućuje uporabu PAM sustava. Na taj način moguće je povezati Kerberos i WWW poslužitelj.

6.7        PAM za MS Windows NT: NI_PAM[24]

NI_PAM je implementacija podskupa PAM-a koja omogućuje autentifikaciju pomoću modula, kao u Linux-PAM-u, na Windows NT platformama.

Da bi se implementirala PAM tehnologija u Windows NT, bilo je potrebno zamijeniti standardnu grafički identifikaciju (Graphical Indentification) i autentifikacijski modul (Authentication module) s modulom koji procesira PAM tablice.

PAM mehanizam omogućuje vrlo visok nivo apstrakcije za identifikaciju i autorizaciju korisnika, skrivajući implementaciju na niskom nivou time što se programer suočava samo s generičkim sučeljem za programiranje (API). Kako je taj mehanizam već prošao praktične provjere na Linux i Solaris platformama, predstavlja vrlo privlačno rješenje za problem jednostruke prijave za rad na sustavu (single sign-on).

Windows NT imaju zamjenjivu (replaceable) komponentu za autentifikaciju korisnika, nazvanu Graphical Identification and Authentication (GINA). GINA je duboko ugrađena u proceduru prijave za rad (logon procedure) na NT računalu, što ju čini vrlo nezgodnom za testiranje i debagiranje. Autori su razvili svoju verziju koja olakšava taj problem time što omogućuje da se mijenjaju autentifikacijski mehanizmi bez potrebe za ponovnim pokretanjem (reboot).

NT komponenta odgovorna za interaktivnu prijavu za rad zove se Winlogon.exe. Njen dio jest GINA. Dizajnirana je tako da bude zamjenjiva, upravo zato da se razvojnim timovima omogući modificiranje autentifikacijske sheme. GINA je DLL biblioteka koju učitava komponenta odgovorna za autentifikaciju korisnika. Kako je ta komponenta zamjenjiva, razvijene su mnoge GINA verzije za različite sheme, npr. Kerberos4-GINA ili (Novell) Netware-GINA. Iako je GINA komponenta zamjenjiva, nema osnovno svojstvo PAM-a: autentifikacijski mehanizmi se u njoj ne mogu zamijeniti – mora se dodavati kôd za svaku shemu.

NI_PAM shema vrlo je slična Linux-PAM-u. Konfiguracijske tablice su identične, no one se na NT platformama spremaju u registry. Poziv NI_PAM-a nije ograničen samo na GINA komponentu – bilo koja aplikacija može se koristiti NI_PAM mehanizmom.

         Implementaciju čine tri komponente: NI_PAM, NI_GINA i moduli koji implementiraju mehanizme.

Text Box: Slika 9- NI_PAM struktura         NI_GINA komponenta se poziva prilikom prijave za rad, te od korisnika traži ime, područje i lozinku. Ona zatim poziva NI_PAM.dll biblioteku koja implementira PAM. Njoj se  prosljeđuju dobivene informacije (korisničko ime, područje – realm i lozinka). Moduli implementiraju specifične mehanizme autentifikacije. NI_PAM čita konfiguracijsku tablicu u registryu i poziva željene autentifikacijske metode. Nakon toga vraća pozivajućoj aplikaciji status (uspjeh ili neuspjeh).

         Zahvaljujući odjeljivanju GINA modula od autentifikacijskih modula, olakšan je razvoj modula. Više nije potrebno ponovno pokretanje računala (reboot) svaki put kad se shema želi promjeniti ili testirati nova. Dodavanje i mijenjanje shema je vrlo lagano i transparentno kako za korisnika, tako i za administratora.

6.8        Sigurnosni aspekti PAM-a[25]

S gledišta aplikacije, PAM je prikladan API (Application Programming Interface). No aplikacije moraju biti vrlo odgovorne u zaštiti okoline u kojoj PAM radi. Loše (ili zlonamjerno) napisana aplikacija može zaobići bilo kakav autentifikacijski mehanizam PAM-a jednostavno ignorirajući poruke i vrijednosti koje autentifikacijski mehanizmi vraćaju. Zadatak i odgovornost aplikacije je dodjela dozvola i pristupa uslugama, a Linux-PAM biblioteka samo preuzima zadaću autentifikacije korisnika

PAM API je dizajniran tako da aplikaciji ne vraća nikakve podatke, nego samo status (uspjeh ili neuspjeh). Aplikacija ne zna koji od modula nije uspješno završio rad, što omogućuje potpunu nezavisnost aplikacije od modula.

 

7         SESAME – “Kerberos” s okusom Starog kontinenta

         Dosadašnji sigurnosni mehanizmi u UNIX sustavima oslanjali su se na brojne individualne aplikacije ograničene na jedno područje, npr. SSL za Internet preglednike (browsers), PGP za poštu itd. Rezultat takvog pristupa bio je nedostatak suradnje među aplikacijama, dupliciranje usluga, složena administracija i veća potencijalna ranjivost.

         SESAME (A Secure European System in A Multivendor Environment) je sveobuhvatna sigurnosna arhitektura, kompatibilna s Kerberosom (ali nije Kerberos), koja omogućuje jednostranu ili uzajamnu autentifikaciju. Koristi kriptografske metode s javnim ili tajnim ključevima, zaštitu podataka u komunikaciji, kontrolu pristupa zasnovanu na ulogama (role-based access control), prosljeđivanje prava (rights delegation), višedomensku (multi-domain) podršku i uslugu praćenja, odnosno kontrole (audit). Zbog svog sveobuhvatnog obujma sigurnosnih usluga, SESAME je vrlo prikladno rješenje za osiguravanje praktično svih UNIX aplikacija na uniforman način ([43]). Standardizacijski dio posla obavila je ECMA (European Computer Manufacturers Association).

Projekt je nastao u prvoj polovici devedesetih godina zbog nepostojanja proizvoda sličnog Kerberosu u Europi (jer Kerberos podliježe strogim američkim zakonima o izvozu kriptotehnologije). U suradnji kompanija Bull, ICL i Siemens, uz djelomičnu potporu Europske komisije, razvijen je sustav koji implementira protokole i za autentifikaciju i za upravljanje kontrolom pristupa (management of access control). Verzija 4 (iz 1995.) je aktualno izdanje ([41]).

Ova arhitektura kompatibilna je s Kerberosom u smislu da može posluživati Kerberos principale. Namjena je bila učiniti SESAME javno dostupnim, no američke vlasti nisu htjele dozvoliti ugradnju Kerberos koda u takav sustav (jer se Kerberos smatrao oružjem zbog kriptografske zaštite). Zato su autori napisali svoju implementaciju dijelova koji pružaju usluge Kerberos principalima.

7.1        SESAME arhitektura[26]

Text Box: Slika 10- SESAME arhitekturaOva arhitektura dizajnirana je polazeći od pretpostavke da je mreža nesigurna, tako da se mora zaštititi integritet (integrity) i povjerljivost (confidentiality) podataka koji se razmjenjuju ([45]). SESAME razumije razliku između ova dva nivo zaštite i omogućuje izbor korištenja ili nekorištenja zaštite povjerljivosti, dok se integritet obavezno štiti. Aplikacijski poslužitelj i klijent mogu, nakon validacije ulaznice, odlučiti da ne koriste zaštitu podataka koju im pruža SESAME (kroz posebnu vrstu poruke), nego da direktno komuniciraju svojim aplikacijskim protokolom.

         SESAME sustav moguće je podijeliti na četiri dijela: klijent (client), poslužitelj (server), sigurnosni poslužitelj domene ili DSS poslužitelj (Domain Security Server) te komponente za potporu (support components). Za komunikaciju (autentifikacijski dio) se koristi UDP protokol, a klijent i poslužitelj nakon toga koriste željeni međuaplikacijski protokol.

7.1.1       Klijent

         Klijentski dio čine obuhvaća korisnik (User – U), korisnički sponzor (User Sponsor, US), APA klijent (Authentication Privilege Attribute Client, APA), SACM komponenta (Secure Association Context Manager) i kôd klijentske aplikacije.

         Korisnik (U) koristi svog sponzora (US), aplikaciju koja omogućuje autentifikaciju korisnika udaljenoj usluzi. APA klijent je implementiran kao aplikacijsko programsko sučelje (API). Pomoću poziva tog sučelja US komunicira sa DSS poslužiteljem da bi autentificirao korisnika i dobio vjerodajnice. SACM je implementiran kao biblioteka subrutina, a omogućuje autentifikaciju podataka i (opcionalno) njihovu tajnost u komunikaciji između klijenta i poslužitelja.

         Kerberos klijentski kod integriran je u US i SACM komponente klijenta ([55]).

7.1.2       DSS poslužitelj i PAC certifikati

         Sigurnosni domenski (DSS) poslužitelj sličan je Kerberos poslužitelju. Glavna razlika je u nazočnosti PAS (Privilege Attribute Server) poslužitelja u SESAME arhitekturi. Ovaj poslužitelj upravlja RBAC mehanizmima za kontrolu pristupa (kasnije objašnjeno). Autentifikacijski poslužitelj (AS) ima istu funkciju kao i u Kerberosu, a KDS poslužitelj (Key Distribution Server) ima ulogu poslužitelja za dodjelu ulaznica, te je na taj način omogućen rad uz jednokratnu prijavu (single sign-on) i upravljanje ključevima. Ukoliko je PVF (PAC Validation Facility) komponenta aplikacijskog poslužitelja (onaj od koga se želi usluga, npr telnet ili NFS) opremljena dugovažećim parom javni/privatni ključ, KDS se može zaobići i sjedničke će ključeve i ulaznicu generirati korisnički SACM ([51]). Ulaznica će biti kriptirana javnim ključem aplikacijskog poslužitelja.

         Autentifikacijski poslužitelj (AS) treba potvrditi udaljenom poslužitelju da korisnički sponzor (US) ima dozvolu za rad u ime određenog korisnika, a sponzoru treba potvrditi da je osoba koja unosi naredbe autorizirani korisnik, tj. da ima ovlaštenje za to. Na taj način onemogućena je uporaba sponzora koji žele neovlašteno prodrijeti u sustav, te neovlaštena (neautorizirana) uporaba računala od strane zlonamjernika.

         U SESAME arhitekturi implementirane su dvije autentifikacijske usluge: prva je temeljena na Kerberos 5 tehnologiji (tajni i sjednički simetrični ključevi), a druga na X.509 mehanizmima autentifikacije (certifikati, javni ključevi). Oba mehanizma omogućuju uzajamnu (mutual) autentifikaciju (npr. da napadač ne bi zavarao korisnika glumeći lažni AS), a drugi mehnizam onemogućuje i napad odabranim pojmovima (dictionary attack). KDS poslužitelj pruža uslugu uzajamne autentifikacije između korisnika i udaljenog poslužitelja. Na raspolaganju je nekoliko autentifikacijskih protokola, u ovisnosti da li je cilj u istoj domeni (domain, analogno Kerberos području – realm) u kojoj je i korisnik ili ne.

         PAS (Privilege Attribute Server) poslužitelj daje informacije, privilegijske atribute (privilege attributes) o korisnicima i korisničkim sponzorima. Implementirana je RBAC shema kontrole pristupa zbog svojih brojnih prednosti. PAS poslužitelj dodjeljuje informacije dodjeljuje u obliku PAC (Privilege Attribute Certificate) certifikata, koji je digitalno potpisani (signed) privatnim ključem PAS poslužitelja. U te informacije spadaju korisnikova uloga (role – npr. admin, user, guest...), trajanje PAC-a itd. Certifikati se razmjenjuju u sklopu proširenja Kerberos protokola. Kerberos daje pravila za rukovanje poljima za proširenje, tako da se PAC certifikati mogu ignorirati od strane onih poslužitelja koji ih ne znaju obraditi ([41]).

Text Box: Slika 11- dodjela PAC cerifikata klijentu ([46])         Na slici je prikazano kako PAC poslužitelj dodjeljuje PAC certifikate. Korisnik se na sustav prijavljuje samo jednom, te mu se u toj fazi dodjeljuju autentifikacijski (AUC) i PAC certifikati. Autentifikacijski certifikat služi da se potvrdi identitet klijenta, a PAC certifikat daje korisniku privilegije. On se daje na uvid udaljenom poslužitelju kad se traži pristup. SESAME koristi tzv. push model: aplikacija daje privilegije korisnika na uvid poslužitelju kad se zahtjeva pristup poslužitelju ([46]). PAS poslužitelj je centralna baza u kojoj su pohranjene informacije o kontroli pristupa pridružene korisnicima ([41]).

         Da bi se spriječilo korištenje PAC certifikata od strane drugih korisnika (ili od strane istog korisnika ali u drugom kontekstu s drugim sponzorom), postoje dva mehanizma za provjeru koristi li PAC certifikat onaj entitet na kojeg glase. Prvi je PPID (Primary Principal [27] Identifier) mehanizam: PAC certifikat sadrži identifikator koji jednoznačno identificira klijenta. Drugi mehanizam je kontrolna vrijednost (Control Value): PAS poslužitelj generira slučajan broj (kontrolnu vrijednost), te svaki entitet koji želi koristiti PAC certifikat mora dokazati da zna tu vrijednost.

         PAC certifikat je zaštićen pomoću zaštitne vrijednosti (protection value) od mjenjanja, tako da se ne može jednostavo ubaciti kontrolna vrijednost u certifikat, a da se to ne otkrije. Zaštitna vrijednost se dobiva pomoću funkcije bez inverza, koja se primjenjeni na kontrolnu vrijednost. Ciljni poslužitelj izračunava zaštitnu vrijednost iz kontrolne, te pretpostavlja da je klijent ovlašten za korištenje certifikata ukoliko se izračunata i zapisana (u certifikatu) vrijednost slažu. Certifikat također sadrži i listu vremenskih perioda kad je valjan. Ti periodi trebali bi biti kratki (sati, ne dani), tako da je korisnički sponzor (US) prisiljen povremeno kontaktirati PAS poslužitelj. Na taj način ograničeno je vrijeme korištenja kompromitiranog ključa ili ovlaštenja (capability).

         Dvije su vrse PAC certifikata: neprosljedivi (non-delegatatable) i prosljedivi (delegatable). Prvi su vezani za određeni identitet (koristeći PPID), dok se drugi mogu opisati kao ovlaštenja koja služe da se delegiraju prava nekog korisnika nekom poslužitelju. Poslužitelj ne može oponašati korisnika, jer poslužitelj ima svoj vlastiti identitet i uvijek se autentificira kao taj poslužitelj, nego samo radi u ime nekog korisnika. Takav poslužitelj daje na uvid PAC certifikat i pridružene kriptografske infomacije da dokaže kako je privremeno ovlašten za korištenje definiranog podskupa korisnikovih prava. Klijent koji želi ostati anoniman traži prosljedivi PAC certifikat (u kojem nije njegov identitet) i delegira ga nekom zamjenskom (proxy) poslužitelju. Ciljni poslužitelj će znati identitet zamjenskog poslužitelja, no ne i identitet korisnika koji stoji iza svega. Kontrolni (audit) tragovi sadrže dovoljno informacija koje omogućuju da administrator razotkrije anonimnog korisnika ukoliko je to potrebno ([41]).

         Format PAC certifikata neovisan je o sigurnosnoj politici u domeni. Detalji o politici nalaze se u komponentama sustava koje stvaraju ili tumače PAC certifikat: to su PAS poslužitelj i logika za kontrolu pristupa u aplikacijskim poslužiteljima ([41]).

7.1.3       Aplikacijski poslužitelj

         Kad aplikacijski poslužitelj primi poruku od aplikacijskog klijenta o želji za uspostavom veze, on prosljeđuje klijentove vjerodajnice svojoj PVF komponenti. Ona provjerava ima li klijent pravo pristupa aplikaciji. Ukoliko je odgovor pozitivan, dekriptiraju se dobiveni podaci i prosljeđuju se integritetski  i  ključevi za zaštitu tajnosti (integrity and confidentiality keys) SACM komponenti na poslužiteljskom stroju. Na se taj način aplikacijski poslužitelj autentificira klijentu (uzajamna autentifikacija), te se uspostavlja sigurna (secure) veza s klijentom.

         PVF (PAC Validation Facility) komponenta može se implementirati bilo kao subrutina unutar aplikacijskog poslužitelja, bilo kao poseban proces (te u tom slučaju može biti zadužena za više aplikacijskih poslužitelja). Treba primjetiti da se mora nalaziti na istom računalu kao i poslužitelji koji ju dijele. Ona  provjerava da li certifikate koristi onaj entitet kojem su izdani, da li su digitalni potpisi na certifikatu ispravni, da li je certifikat još uvijek valjan (da nije istekao), te da li je taj certifikat namijenjen za poslužitelj na kojem se želi primjeniti. Ako neki od ovih zahtjeva nije ispunjen, PVF ne prihvaća certifikat ne otkrivajući sadržaj ostatka ulaznice aplikacijskom poslužitelju. Na taj način onemogućeno je slučajno korištenje krivog certifikata i kompromitiranje tajnih podataka.

7.1.4       Komponente za potporu (support)[28]

         Tri se komponente za potporu koriste unutar implementacije. To su komponenta za upravljanje javnim ključevima (Public Key Management, PKM), komponenta za kriptografsku podršku (Cryptographic Support facility, CSF) i komponenta za kontrolu (Audit Facility).

         PAS poslužitelj, KDS poslužitelj i PVF komponente u ciljnim sustavima koriste PKM za podršku operacijama koje uključuju javne ključeve.

         Komponenta za kriptografsku podršku je odgovorna za pružanje svih kriptografskih usluga.

         Komponenta za kontrolu (audit) bilježi u kontrolne datoteke događaje koji su važni u smislu sigurnosti, tako da se u budućnosti mogu ispitati.

7.1.5       Uloga (role)

         Heterogenost i skalabilnost SESAME privilegija rezultat je temeljenja sustava na  ulogama (roles) ([46]). SESAME koristi RBAC[29] (Role Based Access Control) mehanizme za kontrolu prisupa usluzi. Svakom objektu pridružena je kontrolna lista pristupa (access control list, ACL), koja sadrži parove {uloga, pravo}. Svaki par označava koje akcije smije određena uloga vršiti nad objektom. Subjekt može djelovati u skladu sa svojom ulogom (npr. korisnici A i B mogu oba uzeti ulogu student). Odluke o pristupu donose se u odnosu na ulogu (role) korisnika koji pokušava pristupiti resursu ili pokrenuti aplikaciju.

         Ovakav pristup rezultira značajnim poboljšanjem upravljivosti sustava. Vrlo je lako prebaciti nekoga iz jednog odjela u drugi, jer se radi s listama uloga. Lako je dodavanje ili brisanje korisnika iz sustava. Korisnici mogu uzimati različite uloge, u ovisnosti o zahtjevima organizacije u pojedinim periodima.

         SESAME podržava prosljeđivanje (delegation service). Ta usluga dozvoljava nekom poslužitelju na putu (intermediate server) da primi PAC certifikat i proslijedi ga drugom poslužitelju ([46]).

         Kontrola pristupa na aplikacijskoj strani također je jednostavna. Jedino što se zahtjeva je održavanje jedne kontrolne liste pristupa (ACL) za svaku aplikaciju, koja određuje za što je ovlaštena koja uloga. Nema potrebe znati tko je uistinu korisnik, važna je samo uloga.

         SESAME implementacija pretpostavlja određen oblik politike zasnovane na ulogama: unutar jedne sjednice (login session) korisnik uzima jednu i samo jednu ulogu. Uloge su enumerirane i pridruženi su im identifikatori. Za svakog korisnika postoji lista uloga koje može preuzeti.

7.2        SESAME protokol[30]

         U protokolu se poruke mogu pečatiti, kriptirati i potpisati. Zapečaćene (sealed) poruke se dobivaju dodavanjem (poruci u jasnom tekstu) autentifikacijskog koda poruke, koji se dobiva iz teksta poruke i simetričnog ključa kojim se pečati. Poruka potpisana (signed) privatnim (P-1) ključem sastoji se od poruke u jasnom tekstu i dodatka dobivenog propuštanjem te poruke kroz hash algoritam i potpisivanjem tog sažetka koristeći algoritme s javnim ključevima).

         Ako su korisnik i ciljni poslužitelj u istoj domeni (unutardomenski slučaj), koristi se Kerberos 5 protokol. U međudomenskom (međupodručnom) slučaju koristi se poseban protokol, temeljen na X.509 certifikatima ([51]).

         Sadržaj razmjenjenih  poruka (u unutardomenskom slučaju):

1)KRB_AS_REQ: U, DCU, KDS, i, RLUPK, {AS, N, t}PU-1

         Korisnik (U) šalje autentifikacijskom poslužitelju (AS) autentifikator. DCU označava certifikat korisnika (Certificate of the public key of user), i je cijeli broj (integer) koji predstavlja izazov (a challenge), RLUPK je traženo razdoblje valjanosti (requested lifetime) ključa koji generira AS za korištenje između korisnika (U) i PAS ili KDS poslužitelja. Privatnim ključem korisnika   (PU-1) potpisani su (signed) jednokratna prigodna oznaka (nonce) N i vremenski biljeg (timestamp) t.

 

2)KRB_AS_REP[31]: {BKUPK, i, KDS,     LUPK, t}KU, TGT, A

TGT = {t, LUPK, BKUPK, X}KAPK 

Text Box: Slika 12- SESAME protokol (unutardomenski)A = AS, DCAS, {U, N, N’, t’}PAS-1

 

        Autentifikacijski poslužitelj provjerava certifikat (DCU), iz njega izluči korisnikov ključ KU, provjeri potpis i biljeg t (da poruka nije stara). Korisnikovim ključem se još kriptira i bazični ključ koji generira AS za korištenje između korisnika (U) i PAS ili KDS poslužitelja (BKPUK) s razdobljem valjanosti tog ključa (LUPK).

Ulaznica za dodjelu ulaznica (TGT) kriptirana je dugovažečim tajnim ključem koji znaju AS, PAS i KDS. U njoj su (uz već objašnjene oznake) sadržani i oznaka aplikacijskog klijenta (X) i PPID (Primary Principal Identification), kojeg daje AS koristeći broj certifikata klijenta (the number of DCU).

Autentifikator (A) sadržava certifikat autentifikacijskog poslužitelja. Dio podataka potpisan je (signed) privatnim ključem autentifikacijskog poslužitelja (PAS-1).

3)KRB_PAS_REQ: KDS, LUPK, i’, TGT, A, requested_privileges

                 TGT: {t, LUPK, BKUPK, X}KAPK

                 A: {X, t’’, hash[KDS, LUPK, i’]}BKUPK

                 requested_privileges: SEAL(BKUPK)[t’’, RA]

Ovo je stanardna Kerberos KRB_TGS_REQ poruka plus standardne Kerberos ekstenzije plus SESAME ekstenzija. Kerberos ekstenzija sadrži ulaznicu za dodjelu ulaznica (TGT) namijenjenu PAS poslužitelju plus autentifikator (A), a SESAME ekstenzija sadrži zapečaćene vremenski biljeg (t) i željeni privilegijski atributi (requested privilege attributes, RA). U atribute spadaju uloga, korisničko ime itd (vidi [52]). U autentifikatoru se nalazi rezultat propuštanja određenih podataka kroz hash algoritam.

4)KRB_PAS_REP: new_session_key, PAC, ticket

                 new_session_key = {BKXK, i’, KDS, LXK, t}BKUPK

                 PAC = SEAL(BKUPK)[t’’, {PA, PPID}PP-1]

                 ticket = {t, LXK, BKXK, X, PPID}KAPK

Ovo je KRB_TGS_REQ poruka s nekim proširenjma. Ulaznica koja se šalje je ulaznica za dodjelu ulaznica sa SESAME ekstenzijom, te sadrži PPID (identifikator primarnog principala, tj. radne stanice, generiran posebno za ovu sjednicu). U ulaznici je nalazi sjednički ključ (BKXK) kojeg će dijeliti aplikacijski klijent X i KDS. Novi ključ služi za autentifikaciju zahtjeva za ulaznicama        temeljenim na novoj ulaznici za dodjelu ulaznica (u koju je uključen PPID). Uz ključ nalazi se razdoblje valjanosti tog sjedničkog ključa. PAC certifikat sadrži i PA (privilege attributes, npr. razdoblje valjanosti certifikata, uloga itd.) i PPID, potpisane privatnim ključem PAS poslužitelja. PPID se tu nalazi da bi se PA atributi vezali uz ključ BKXV. Taj ključ je bazični ključ koji generira X za korištenje između njega i PVF komponente aplikacijskog poslužitelja Y.

U normalnoj Kerberos autentifikaciji trebala bi još dva koraka (komunikacija s KDS poslužiteljem) da se dobije sjedničkog ključa BKXV. U ovom slučaju PVF (V) ima dugovažeći javni ključ PV poznat klijentu X,  te aplikacijski klijent X sam generira BKXV. Zbog toga se mogu ispustiti koraci 5 i 6.

5)KRB_TGS_REQ: (ispušten)

6)KRB_TGS_REP: (ispušten)

7)SES_INIT_CTXT: SEAL(IKXY)[SEAL(BKXV)[M], X, t’’’, n]

        M – SESAME token: PAC, ticket, dialogue_key_package, target_id

        PAC = {PA, PPID}PPAS-1

        ticket = {t, LXV, BKXV, X, PPID}PV

           dialogue_key_package = rs1, rs2

        target_id = Y (application server)

Integritetski ključ (integrity key) IKXY izveden je iz BKXV (za korištenje između X i Y) da bi se autentificirao X i osigurao integritet podataka. SESAME token sadrži informacije koje će PVF trebati da izvede IKXY.  LXV označava razdoblje valjanosti sjedničkog ključa. PV je javni ključ PVF komponente. n predstavlja mesage sequence number.

SESAME razlikuje usluge integriteta podataka i tajnosti podataka. Slučajni ofseti (random offsets) rs1 i rs2, koje daje X, koriste se za izračunavanje integritetskog ključa IKXY i ključa za tajnost dijaloga (confidentiality dialogue key) CKXY:

        IKXV = hash1[BKXV, rs1]

        CKXY = hash2[BKXV, rs2]

7a)SACM-to-PVF: SEAL(BKXV)[M]

Poslužitelj (Y) prosljeđuje PVF komponenti na procesiranje informaciju primljenu od X. Prijenos se obavlja unutar istog stroja i SESAME pretpostavlja da mehanizmi kontrole pistupa na računalu omogućuju zadovoljavajući integritet, povjerljivost (confidentiality) i autentifikaciju.

7b)PVF-to-SACM: IKXY, CKXY

        PVF komponenta dekriptira ulaznicu za uslugu svojim privatnim ključem PV-1 da bi došla do bazičnog ključa BKXV (tj. sjedničkog ključa). Ova bi komponenta trebala provesti slijedeće provjere:

·         provjeriti pečat na cijeloj poruci pomoću BKXV

·         provjeriti da li identifikator poslužitelja (Y) unutar poruke odgovara identitetu poslužitelja u čije ime PVF trenutno radi

·         provjeriti digitalni potpis na PAC certifikatu pomoću PP (javnog ključa PAS poslužitelja)

·         provjeriti odgovara li PPID iz certifikata PPID oznaci iz ulaznice za uslugu

·         primjeniti one provjere kontrole pristupa koji su potrebni, temeljene na autibutima unutar certifikata i identitetima aplikacijskog klijenta X i aplikacijskog poslužitelja Y

Tada PVF daje aplikacijskom poslužitelju (Y) integritetski i ključ za povjerljivost dijaloga. Opet se pretpostavlja da mehanizmi kontrole pristupa daju dovoljnu zaštitu za ovu poruku.

8)SES_INIT_CTXT_COMPLETE: SEAL(IKXY)[t’’’, n’]

Poslužitelj Y se autentificira šaljući poruku zapečaćenu dijeljenim integritetskim ključem. Na prvi pogled se može učiniti da je ovaj korak podložan slanju snimljenih dijelova (replay) iz koraka 7. To nije moguće iz dva razloga. Prvi je taj što se u ASN.1 protokolu koji SESAME koristi, različiti zapečaćeni tipovi (type) imaju različite oznake tipova (type tags). Na taj se način zapečaćeni jasni tekst jednoznačno prepoznaje kao korak 7 ili korak 8. Drugi razlog je to što X u koraku 7 uključuje svoj identifikator u poruku koju pečati.

9)SES_DATA: opcionalna zaštita podataka koji se šalju; klijetn i poslužitelj mogu se dogovoriti da    ne koriste ove poruke, nego da direktno komuniciraju svojim aplikacijskim protokolom;          postoji više inačica ove poruke (u ovisnosti tko kome šalje i koja se zaštita koristi):

    X®Y: SEAL(IKXY)[t(1), n, m)]

         Samo zaštita integriteta, a m poruku. n predstavlja redni broj poruke u slijedu (message sequence number).

    X®Y: SEAL(IKXY)[t(1), n, {m}CKXY]

         Zaštita i integriteta i povjerljivosti

    Y®X: SEAL(IKXY)[t(1), n’, m]

    Y®X: SEAL(IKXY)[t(1), n’, {m}CKXY]

         Strana koja je inicirala uspostavu veze (klijent) šalje poruku SES_CTXT_ABORT kad više ne treba usluge udaljenog poslužitelja.

7.3        Kriptografija u SESAME sustavu

         Kao što se iz opisa poruka vidi, u SESAME sustavu se koriste simetrični i asimetrični algoritmi (algoritmi s javnim ključevima), kako za kriptiranje, tako za potpisivanje i pečaćenje. Ključeve generira (za unutrardomensku komunikaciju) ili prevodi (translates, za međudomenski slučaj) KDS poslužitelj ([47]).

         U stvarnoj implemetaciji su korišteni slijedeći algoritmi([51]):

·         pečaćenje: DES-MAC

·         kriptiranje simetričnim ključem: DES u CBC modu zajedno s MD5 (kriptirao se i sažetak, te se slao uz poruku)

·         potpisivanje privatnim ključem: 512-bitni RSA plus MD5

·         kriptiranje javnim ključem: 512-bitni RSA

·         hash (sažetak): MD5

         Čak i u Europi može biti problema ako se koristi jaka kriptografija. U nekim zemljama, npr. Francuskoj, zabranjeno je korištenje kriptografije (osim uz posebnu dozvolu). Zbog toga je, na prijedlog SOGIS (Senior Officials Group on Information Security), DES komponenta za kriptografiju zamijenjena komponentom koja koristi jednostavan XOR (ekskluzivno ili) algoritam za kriptiranje. Kako je SESAME modularno dizajniran, vrlo je lako zamijeniti ju DES ili IDEA komponentom ([47]).

7.4        UNIX aplikacije i SESAME

         SESAME dozvoljava programerima ugradnju SACM komponente u klijente i poslužitelje preko poziva GSS API sučelja. GSS API je sučelje za osiguravanje (securing) umreženih klijent/poslužitelj aplikacija, neovisno o korištenim mehanizmima. Programerima se na raspolaganje stavljaju već gotove biblioteke koje podržavaju pozive preko GSS API sučelja. Oni samo trebaju razumjeti kako koristiti biblioteke. Budući da SESAME nudi veći obujam usluga nego Kerberos, neki pozivi koje SESAME omogućuje nisu podržani u Kerberos implementaciji GSS API ([43]). Kerberos GSS API nudi samo uzajamnu autentifikaciju, tajnost (confidentiality) i usluge zaštite integriteta. SESAME GSS API još nudi i kontrolu pristupa i usluge kontrole (audit).

         U distribuciji dolaze već sezamizirane najpopularnije aplikacije (telnet, ftp itd.).

7.4.1       Linux verzija[32]

         U [53] i [54] je opisano prenošenje SESAME arhitekture (originalno razvijene za AIX sustave) na Red Hat Linux platformu.

         Sigurnosni poslužitelj (DSS) uključuje KDS, AS i PAS poslužitelje, te kontrolnog (audit) daemona. Aplikacijski poslužitelj (application server) ima PVF i kontrolog daemona, te treba kontrolirati pristup aplikacijama. Aplikacijski klijenti (application clients) trebaju imati samo kontrolnog (audit) daemona. DSS se može ponašati i kao aplikacijski poslužitelj, a bilo koji aplikacijski poslužitelj može se ponašati i kao aplikacijski klijent ([53]).

         Implementiravši verzijom za Red Hat Linux, autori su sezamizirali NFS (Network File System),  XDM (X Display Manager), telnet, RPC (Remote Procedure Calls) i “r” komande za dotičnu implementaciju.

Text Box: Slika 13- SESAME domena ([54])Slika prikazuje komponente implementirane Linux domene. Sigurnosni poslužitelj sadrži autentifikcijski poslužitelj (AS, za autentifikaciju korisnika), PAS poslužitelj (Privilege Attribute Server, za opskrbljivanje korisnika vjerodajnicama), KDS poslužitelj (Key Distribution Server, za generiranje sjedničkih ključeva i ulaznica koje koriste aplikacije), te kontrolni poslužitelj (Audit Server, za prikupljanje kontrolnih informacija preko mreže). Aplikacijski poslužitelji imaju vlastite PVF komponente (Privilege Verification Facility) koje provjeravaju valjanost korisničkih vjerodajnica izdanih u obliku PAC (Privilege Attribute Certificate) certifikata. Aplikacijski klijent (u ovom slučaju XDM) se autentificira sigurnosnom poslužitelju i dobiva PAC certifikat. Slika također pokazuje da se aplikacijski poslužitelji mogu ponašati kao aplikacijski klijenti, dozvoljavajući korisnicima pristup klijentskim komponentama dok su na istom računalu pokrenute poslužiteljske komponente. Certificate Authority komponenta izrađuje certifikate, te ne bi smjela biti spojena na mrežu.

         XDM je aplikacija koja omogućuje prijavu korisnika na računalo i uspostavu X Window sjednice (session) s tim računalom. Sezamizirana verzija traži od korisnika unos korisničkog imena i lozinke prilikom prijave (poput obične verzije) te izbor uloge (role) s koju korisnik želi preuzeti nakon prijave. Korisnik se ne prijavljuje na lokalno računalo, nego na sigurnosni poslužitelj. Ne autentificira ga XDM, nego SESAME. Ukoliko korisnik ima korisnički račun na aplikacijskom klijentu i autentifikacija je pozitivna, korisnik je prijavljen na računalo. Ukoliko ga nema, SESAME stvara privremeni račun i daje XDM programu PAC certifikat. Taj certifikat koriste aplikacijski klijenti da bi autentificirali korisnika udaljenim poslužiteljima. Certifikat se uništava prilikom odjave.

Text Box: Slika 14- sezamizirani telnet ([54])         Klijentski program (telnet) šalje korisnikov PAC certifikat (umjesto lozinke) poslužiteljskom programu (telnetd). Poslužiteljski program šalje potvrdu o primitku ukoliko je certifikat prihvaćen, te svoje vjerodajnice ukoliko se traži uzajamna autentifikacija.

 

 

7.5        Kerberos i SESAME[33]

         Kerberos i SESAME sustav imaju puno zajedničog i nude slične usluge. Oba su sigurnosni sustavi koji korisnicima omogućuju sigurno jednostruko (single sign-on) prijavljivanje i korištenje usluga u mreži. Korisnici se autentificiraju davanjem lozinke, a nakon toga dobivaju ulaznicu koju mogu iskorisiti za pristupanje poslužiteljima u mreži (SESAME ulaznica još sadrži i prava pristupa). Oba sustava temeljena su na klijent-poslužitelj modelu. Postoje autentifikacijski poslužitelj, poslužitelj za dodjelu ulaznica i aplikacijski poslužitelji. Ti poslužitelji posjeduju tajne kriptografske ključeve koji im služe za zaštitu vjerodajnica i autentifikacijskih podataka na putu kroz mrežu,  što znači da korisnici ne šalju lozinku kroz mrežu.

         Mats Persson i Ulf Lindbergh su u sklopu jedne radionice s područja primjenjene sigurnosti u mrežnim sustavima na sveučilištu u Linkopingu odlučili ispitati kompatibilnost SESAME i Kerberos arhitekture. Tijek pokusa i rezultate su objavili u [49].

         Uporabili su besplatnu implementaciju Kerberosa 5 za Linux poznatu pod imenom Heimdal. Kerberos ulaznicu za dodjelu ulaznica (TGT), koju su dobili od Kerberos poslužitelja, poslali su SESAME poslužitelju za dodjelu ulaznica (KDS), a SESAME ulaznicu su poslali Kerberos poslužitelju za dodjelu ulaznica (TGS).

         Kao zaključak navode da “izgleda” da SESAME podržava Kerberos 5 protokol, te da “vjerojatno” može obrađivati zahtjeve Kerberos aplikacija. Usto, zaključuju da SESAME može vršiti autentifikaciju u Kerberos stilu. Smatraju da su sustavi “vjerojatno kompatibilni” zbog toga što “podržavaju GSS API sučelje”.

         Da se podsjetimo, autori SESAME sustava su od početka željeli kompatibilnost s Kerberosom, tako da se mogu posluživati Kerberos klijenti. Sve ekstenzije su prilagođene korištenju unutar Kerberos implementacije, koja je predviđala da će neki sustavi unositi svoja proširenja koje neće svi poslužitelji razumijeti. Zbog toga je implementacija Kerberos poslužitelja napravljena tako da oni ignoriraju proširenja koja ne razumiju (u ovom slučaju proširenja koja unosi SESAME poslužitelj). Persson i Lindbergh mogli su samo potvrditi kompatibilnost SESAME arhitekture sa Kerebrosom u smislu sposobnosti pružanja usluge Kerberos klijentima.

         U oči ipak bode što su autori toliko neodređeni, pogotovo što se tiče posluživanja SESAME klijenta od strane Kerberos TGS poslužitelja. Meni je zvučalo logično da Kerberos poslužitelj nije u stanju uslužiti SESAME klijenta zbog nepoznavanja SESAME ekstenzija, no Persson i Lindbergh u zaključku tvrde da je “sve bilo u redu” navodeći da se “SESAME može konfigurirati tako da vrši autentifikaciju u Kerberos 5 stilu”. Iako nisam do kraja uvjeren da Kerberos može poslužiti SESAME klijenta, pogotovo zbog neodređenosti koja se provlači kroz tekst, to bi se moglo objasniti korištenjem Kerberos 5 protokola unutar domene.

7.6        SSL vs. SESAME[34]

         Problem osiguravanja mreža može se promatrati s raznih gledišta: osiguravanjem na aplikacijskom nivou, osiguravanjem na mrežnom (transportnom) nivou ili fizičkom sigurnošću.

Text Box: Slika 15-SESAME i SSL u OSI modelu         SSL je namjenjen osiguravanju transportnog sloja, neovisno o aplikacijama koje se koriste. Omogućuje autentifikaciju entiteta te autentifikaciju i povjerljivost podataka. Entitet nije neki korisnik, nego računalo. U SSL-u nedostaje esencijalna usluga poput autorizacije.

 

         Za razliku od rješenja u transportnom sloju koje nudi SSL, SESAME nudi rješenja u aplikacijskom sloju. Dok je SSL samo standard koji definira način osiguravanja komunikacije dviju strana, SESAME je čitava arhitektura. U SESAME sustavu dovoljno je jednom se prijaviti na sustav da bi korisnik bio autentificiran (single sign-on), dok SSL nema definiranu takvu uslugu.

         SSL je dizajniran posebno za WWW interakcije i nudi više opcija i bolje performanse nego SESAME u jednostavnoj konfiguraciji opisanoj u [50]. SESAME je pak prikladniji za rješenja koje traže finiju kontrolu pristupa (npr. NFS).

         Na kraju, SSL je u vlasništvu tvrtke Netscape, koja diktira promjene i razvoj, te ima sva prava na njega. SESAME je pak javno dostupan, otvoren i skalabilan sustav, čiji razvoj ne koče autorska ni vlasnička prava, te nudi usluge za širok raspon sustava, od Intranet mreža do Interneta. Dok američki izvozni zakoni koče izvoz jače enkripcijske tehnologije, SESAME zbog svoje modularnost omogućuje da se slaba kriptografska jedinica dobivena uz sustav zamjeni bilo kojom drugom.

7.7        Nedostaci i moguća poboljšanja SESAME arhitekture[35]

         Ovoj arhitekturi ne stavljaju se veće zamjerke, što zbog pažljivog dizajna, što zbog kratkog vijeka postojanja. Zamjerke se uglavnom stavljaju implementaciji. Primjer je korištenje XOR kriptiranja umjesto DES ili sličnog jačeg algoritma (zbog različitih zakona o korištenju kriptografije), no XOR modul se može zamjeniti DES, IDEA ili nekim drugom.modulom Privatni korisnički ključevi (koji se rabe za generiranje digitalnih potpisa) zaštićeni su samo UNIX mehanizmima kontrole pristupa na računalima na kojima se nalaze. Za bolju zaštitu, mogu se uporabiti kartice koje sadržavaju tajne podatke, te ih po potrebi i procesiraju – slično JavaCard tehnologiji[36] ili sustav sličan PGP-u (traži neku vrstu lozinke – passphraze).

         Najveća zamjerka je što se aplikacije moraju sezamizirati (prilagoditi radu sa SESAME sustavom), no kako  SESAME podržava GSS API sučelje, to nije prevelik zadatak. Nekoliko najčešće korištenih aplikacija dolazi uz distribuciju.

         Kako SESAME nudi širok raspon usluga, može osigurati (secure) sve važnije UNIX aplikacije na uniforman i skalabilan način. Sezamiziranje (prilagođavanje aplikacija da koriste usluge SESAME sustava) je jednostavno zbog korištenja GSS API poziva. Sezamizirane aplikacije nude brojne prednosti: jednostranu ili obostranu autentifikaciju korištenjem Kerberosa ili javnih ključeva, tajnost i integritet podataka prilikom razmjene, kontrolu pristupa zasnovanu na RBAC shemi (uloge), prosljeđivanje (delegation) prava, uslugu kontrole (audit) i višedomensku podršku. Razvojem Interneta i elektroničke trgovine nameće se potreba za odgovarajućom zaštitom. SESAME je već od početka dizajniran imajući u vidu takve zahtjeve, nudeći rješenja za slabe točke tadašnjih rješenja. Korištenjem tehnologije javnih ključeva dobiva se dodatna funkcionalnost, a sustav kontrole pristupa temeljen na ulogama (roles) pokazao se kao vrlo dobar odgovor na zahtjeve World Wide Weba ([41]). Pokus u kojem je inkorporiran SESAME kontrolni sustav u WWW preglednik daje osnove za velika očekivanja ([51]).

 

 

8         Mehanizmi alternativni Kerberosu

8.1        Vatrozidovi (firewalls)

Vatrozid (firewall) je mrežni uređaj koji filtrira određene tipove paketa koji idu s jedne strane na drugu. Namjena mu je rješavanje istih problema koje i Kerberos pokušava riješiti. Za razliku od Kerberosa, koji odbija pružati mrežne usluge neautentificiranim korisnicima, vatrozid dijeli mrežu na “sigurnu” unutrašnjost i “nesigurni” vanjski dio.

Zagovornici vatrozidova smatraju da je UDP nesiguran, djelomično zato jer mnogi “nesigurni” protokoli koriste UDP. Budući da Kerberos koristi UDP protokol[37], mogu se pojaviti problemi u radu prilikom inetrakcije s vatrozidovima. Neki vatrozidovi mijenjaju adrese računala unutar zaštićene mreže (izvana se vidi kao jedna adresa, a on im dodjeljuje druge i preusmjerava pakete), što Kerberos smatra krivotvorenjem, tj. napadom. U nekim konfiguracijama UDP portovi preko kojih Kerberos komunicira nisu otvoreni za promet paketa. Simptomi pokušaja korištenja Kerberosa iza vatrozida su nemogućnost dobivanja ulaznica ([10]).

Bob Blakley, arhitekt sigurnosnih sustava iz IBM-a, u tri točke objasnio je zašto smatra da su vatrozidovi precijenjeni i zašto su zbog toga kriptografske tehnike korištene u Kerberosu superiornije nad tehnikama zaštite podataka i korisnika kojima se koristi vatrozid ([30]):

1. Naše mjesto je okruženo i zaštićeno – pretpostavka je da jedini put u/iz mreže vodi kroz vatrozid, tj. nema stražnih vrata u mrežu. U stvarnosti je to rijetko točno. Korisnici mogu stvoriti svoja vlastita stražnja vrata koristeći modeme, terminale ili aplikacije tipa “PC Anywhere” (za administriranje računala preko mreže) tako da mogu raditi i od kuće, ne samo u uredu. U nekim akademskim ili istraživačkim zajednicama zaposleni mogu tražiti takve iznimke što se tiče vatrozida (da bi mogli surađivati s drugim zajednicama) tako da dođe na isto kao da nema vatrozida.

2. Unutra su samo “dobri dečki” (Nobody here but us chickens) – kod vatrozidova se pretpostavlja da su svi “loši dečki” vani, a da su unutra samo ljudi od povjerenja. Statistika pak otkriva da je velik broj krivičnih djela u korporacijama počinjen upravo iznutra, od zaposlenika.

3. Podaci (riječi) ne mogu nanijeti štetu (Stick and Stones may break my bones, but words  will never hurt me) – nove softverske tehnologije (Javascript, ActiveX, VBScript) brišu granice između podataka i aplikacija, te se često egzekutabilni fragmenti (makro-naredbe, Java apleti) mogu ugraditi u podatke. Korisnici su tako bespomoćni pred gomilom napadača (Worm.ExploreZip, Melissa s bezbroj inkarnacija te razni drugi virusi i crvi koji se prenose e-mailom), od čega ih ova metoda ne može zaštititi.

         Nedostaci i problemi zbog istovremenog korištenja Kerberosa i vatrozida mogu se izbjeći ako se omogući korištenje UDP portova na kojima Kerberos komunicira (88 za verziju 5, a 750 za verziju 4), ako se koristi TCP veza preko nekog nestandardnog porta ili ako se koristi HTTP protokol da bi se dobile ulaznice. Budući da se u zadnje dvije metode ne prenose “ispravni” tipovi podataka, administrator vatrozida bi ih mogao smatrati napadačkim ukoliko se one koriste bez prethodnog dogovora s njim ([10]).

8.2        Secure RPC

Secure RPC (SRPC, zaštićeni poziv udaljenih procedura) razijen je u kompaniji Sun Microsystems sredinom osamdesetih u svrhu poboljšanja sigurnosti mreža zasnovanih  na UNIX operacijskim sustavima (primarno na njihovoj verziji UNIX-a, SunOS-a). Sličan je Kerberosu, no za razliku od njega SRPC je ugrađen u sustav poziva udaljenih procedura (RPC). To znači da se aplikacije ne moraju posebno prilagođavati kao što je bio slučaj kod Kerberosa (kerberizirati), nego je SRPC transparentna modifikacija poziva udaljenih procedura (RPC[38]) na niskom nivou, tako da će svaka usluga temeljena na RPC-u raditi i s SRPC-om.

Za zaštitu povjerljivih informacija koje se prenose preko mreže preko mreže koristi se DES enkripcija (kao i kod Kerberosa), no korisnikov tajni ključ sprema se na NIS (Network Information Service) poslužitelju. Zbog toga SRPC ne zahtjeva posebno zaštićen “autentifikacijski poslužitelj” da bi ustanovio identitet mrežnih korisnika ([29], str. 282). Za dogovor oko enkripcijskog ključa (za razmjenu podataka), klijent i posluželj se koriste metodom nazvanom “eksponencijalna razmjena ključeva” (exponential key exchange). Objavljuju javne ključeve (preko NIS poslužitelja), te obojica nezavisno dolaze do istog konverzacijskog (conversation) ključa, kombinirajući svoj privatni s javnom ključem onog drugog. Buduće transakcije kriptiraju se konverzacijskim ključem. Enkripcija korištenjem para javni/privatni ključ je prilično spora, stoga se koristi samo za izmjenu DES ključa.

NIS (Network Information Service) je distribuirani sustav baza podataka koji dozvoljava sustavima dijeljenje datoteka s lozinkama i druge datoteka preko mreže. Olakšava održavanje mreže jer se sve konfiguracijske informacije o korisničkim računima spremaju na jedno računalo, NIS glavni poslužitelj. Zbog toga što drži tako osjetljive materijale poput lozinki, vrlo ga je važno ispravno konfigurirati.

Delikatan problem je pronaći odgovarajući par {javni ključ, privatni ključ}. Vrlo je teško zapamtiti duge nizove znamenki (jer onda bolja zaštita), a teško je to izvesti i iz UNIX lozinke. Taj problem se rješava tako da se održava baza podataka (pomoću NIS mrežnog sustava) s imenima korisnika i njihovim privatnim i javnim ključevima. Tajni ključ kriptira se DES algoritmom koristeći korisnikovu lozinku kao ključ. Svaki slog u bazi podataka sastoji se od korisnikovog mrežnog imena, javnog ključa i kriptiranog privatnog kluča.

Aplikacija na radnoj stanici koristi korisnikov privatni ključ i poslužiteljev javni da bi generirala sjednički (session) ključ (poslužitelj je to učinio sa svojim privatnim i korisnikovim javnim ključem). Zatim se generira 56-bitni slučajni konverzacijski ključ i šalje se poslužitelju, kriptiran sjedničkim ključem. Taj konverzacijski ključ koristi se tijekom dotične prijave rada. Kod svake nove prijave generira se novi konverzacijski ključ opisanim postupkom. Nakon završenog rada, prije odjave sa poslužitlja, treba se uništiti kopija tajnog ključa u radnoj stanici.

Poslužitelj zna tko je korisnik jer je paket kriptiran konverzacijskim ključem. Jedini način na koji ga je korisnik mogao dobiti je generirajući ga iz poslužiteljevog javnog i svog privatnog ključa, a svoj privatni ključ je korisnih mogao saznati samo od NIS poslužitelja, dekriptirajući ga. Dakle, korisnik mora znati i svoju lozinku da bi dekriptirao svoj privatni ključ.

Treba primjetiti da se lozinka nikad ne prenosi preko mreže i da se privatni ključ prenosi kriptiran korisnikovom lozinkom. Nema nekih tajnih informacija zbog kojih bi poslužitelj morao biti posebno zaštićen, kao što je slučaj u Kerberos sustavima.

         Unutar zaglavlja svakog SRPC zahtjeva šalje se vremenski biljeg (timestamp), koji služi za sprečavanje ponovnog slanja snimljenih starih paketa (replay attack). Zbog toga je vrlo važno da se klijent i poslužitelj dogovore oko vremena: ako je razlika između njihovih satova prevelika, poslužitelj neće prihvatiti klijentove zahtjeve. Administrator treba odrediti vremensko okno, tj. kolika smije biti maksimalna razlika između klijentovog i poslužiteljevog sistemskog sata da bi zahtjevi bili prihvatljivi. Veće okno smanjuje opasnost od moguće nesinkroniziranih satova, no povećava opasnost od uspješnog napada (jer stari paketi su valjani duže vrijeme). Manje okno smanjuje pak opasnost od upada u sustav, no mogu se češće pojaviti problemi u radu zbog razlike u sistemskom vremenu. Sun Microsystems preporučuju da se okno postavi na pet minuta za aplikacije kod kojih je vrlo važna sigurnoast, a 60 minuta smatraju prihvatljivom normalnom vrijednošću.

Za eliminaciju problema sinkronizacije satova može se iskoristiti usluga poput NTP (Network Time Protocol). On i bez te usluge satovi se tipično razlikuju u samo nekoliko sekundi unutar jednog radnog dana.

SRPC, kao i svaki sigurnosni protokol, ima  nedostataka ([29]):

·         privatni ključ možda nije zadovoljavajuće osiguran u radnoj stanici: sprema se lokalno, pa ga vještiji napadač može saznati (ako zadobije administratorske ovlasti nad stanicom) ili ako postavi svoje verzije pograma za rad

·         svaki mrežni klijent mora biti posebno prilagođen da bi koristio SRPC: iako je SRPC transparentna modifikacija RPC-a, klijenti moraju biti modificirani da zhtjevaju AUTH_DES autentifikaciju

·         sporije performanse (dekriptiranje)

·         javni ključ može biti probijen: informacija kriptirana Diffie-Hellman sustavom (korišten u SRPC-u) može se dekriptirati ako se izračuna diskretni logaritam (discrete logarithm) javnog ključa. To je uspjelo znanstvenicima u AT&T laboratorijima 1989., iako postupak nije javno objavljen. Prema njihovim izvješćima, trebalo im je samo nekoliko minuta (rada računala) za izračunavanje privatnog ključa. Rješenje je koristiti dulji ključ

Na kraju, SRPC se pokazao, unatoč nedostacima,  kao izuzetno dobar sustav za zaštitu, naročito na višekorisničkim strojevima (što je nedostatak Kerberosa).

8.3        SSL

         SSL (Secure Socket Layer) je protokol za (uzajamnu) autentifikaciju baziran na javnim ključevima i dodjeli certifikata. Klijent i poslužitelj koji posjeduju certifikate mogu se uzajamno autentificirati i razmjeniti tajne simetrične sjedničke ključeve koji će se koristiti u daljnjoj komunikaciji.

         Na početku sjednice klijent i server vrše “rukovanje” (handshake), za vrijeme kojeg se dogovaraju o algoritmima i ključevima koji će se koristiti. Autentificiraju se strojevi (računala), ne korisnici.

         Prednosti nad Kerberosom su:

·         ne zahtjeva se treća strana kojoj se vjeruje

·         veza se može uspostaviti čak i ako ona druga strana nema “tajnu” (ključ ili lozinku)

         Zbog toga je SSL vrlo korišten za sigurnu komunikaciju preko Interneta i za aplikacije gdje je baza korisnika vrlo velika i nepoznata unaprijed.

         SSL ima i nekoliko nedostataka. Prvi se tiče opoziva ključa. Kad je dodijeljeni certifikat kompromitiran, mora biti povučen, no tada se javljaju teškoće oko toga kako obavijestiti poslužitelje da je certifikat nevaljan. Ili obavijest treba dugo kružiti između svih poslužitelja ili se treba uvesti poseban poslužitelj kod kojeg će svi ostali provjeravati ispravnost certifikata – treća strana koja mora biti uvijek na raspolaganju. Time se eliminira jedna od glavnih prednosti SSL-a nad Kerberosom. Certifikat mora biti spremljen na disk, što znači da netko može doći do njega i probiti ga (ako je kriptiran lozinkom). Za Kerberos autentifikaciju pak treba samo lozinka, nikakav ceritifkat. Za upotrebu SSL-a se mora platiti, a razvoj ne podliježe otvorenim standardima. Nove tehnologije (npr. nova vrsta SmartCard kartica) se lakše implementiraju u Kerberos nego u SSL.

         SSLK5 je paket koji koristi SSLv3 protokol (implementiran pomoću besplatne verzije SSL-a nazvane SSLeay) za prenošenje zahtjeva za autentifikaciju (KRB_AS_REQ) i njegovih odgovora između klijenta i modificirane verzije Kerberos V5 autentifikacijskog poslužitelja (AS). Na taj način implementiran je Alternate Authentication Service (AAS). Taj modificirani autentifikacijski poslužitelj može raditi paralelno s običnim, tako da može izdavati ulaznice za dodjelu ulaznica za njega. Klijent (sslk5) je vrlo sličan kinit programu i oprivhaća većinu opcija, no koristi X.509 certifikat kao dokaz identiteta za autentifikaciju. SSLv3 autentifikacija koristi X.509 certifikate koji mogu biti iskorišteni za dobivanje ulaznice za dodjelu ulaznice. Certifikati za sslk5 bi trebali imati uobičajeno ime, koje je isto kao ime TGT principala ([22]).

Program (daemon) sslk5d je MIT autentifikacijski poslužitelj koji prihvaća zahtjeve za autentifikacijom preko TCP uz pomoć SSLv3. Treba primjetiti da “normalan” Kerberos koristi UDP protokol. Kako rade na istom portu a različitim protokolima, mogu paralelno raditi i korisiti istu bazu podataka s korisnicima. Zahtjeva svoj valstiti certifikat i ključ ([22]).

8.4        AFS (Andrew File System)

         AFS je distribuirani datotečni sustav koji omogućuje suradnju računala (klijenata i poslužitelja) glede dijeljenja datotečnih resursa preko mreža. Poslužitelji se administrativno grupiraju u ćeliju (cell), koja tvori jedinstven, kohezivan datotečni sustav (tipično skup računala koje koriste istu Internet domenu) ([34]).

         Kerberos korišten u AFS (Andrew File System) sustavu razvijen je iz verzije 4, no prije nego je protokol bio formaliziran. Standardni AFS klijenti odbacuju ulaznicu za dodjelu ulaznice (TGT) nakon dobvene ulaznice za AFS uslugu, što znači da se ne mogu dobiti ulaznice za ostale usluge koristeći vlastiti AFS token.

         AFS sustav koristi drugačiji protokol od Kerberosa V4, no razumije i MIT Kerberos V4 protokol. Njihova međusobna komunikacija razlikuje se u dosta detalja, tako da nije praktična. U algoritmu za pretvaranje lozinki u ključ AFS koristi i ime domene, dok Kerberos V4 ne. Protokol promjene lozinki je također drugačiji. U principu AFS i Kerberos mogu međusobno pružati usluge nakon što je dobivena ulaznica za dodjelu ulaznica. S njom klijenti bilo kojeg sustava mogu tražiti uslugu bilo kojeg sustava, no najbolje je iapk izabrati jednu implementaciju i čvrsto se držati nje ([01]).

         AFS sustav se može nadograditi odgovarajućim kompletima na standardan Kerberos V4 sustav.

8.5        OSF DCE

         OSF DCE (Open Software Foundation Distributed Computer Environment) je sveobuhvatan pokušaj da se ostvari pravi distribuirani sigurnosni sustav. Pruža osiguranje za sve umrežene sustave. Uključuje pozive udaljenih procedura (RPC) i dopunske mehanizme za olakšavanje distribuiranog računarstva. Pozivi udaljenih procedura su jedna od metoda organizacije distribuiranog sustava. Obično se izabire jer omogućuje dobro iskorištavanje vještina programera. Pišući aplikaciju za distribuirani sustav, programer može strukturirati kod distribuiranog sustava slično kao za nedistribuiranu verziju. Mrežna komunikacija se krije iza onog što izgleda kao običan poziv funkcije ([33]).

         Da bi se prilagodio širokom rasponu veličina sustava, DCE sustav dozvoljava da velika okružja budu podijeljena u manja, kojima se može nezavisno upravljati. Svaka takva jedninica, nazvana ćelija (cell),  osnovna je jedinica za rad i administiranje ([45]).

         Autentifikacija je zasnovana na Kerberosu 4. Principali unutar ćelije dijele zajednički autentifikacijski poslužitelj (AS). Prilikom prijave za rad, AS provjerava korisnika i dodjeljuje mu ulaznice. Principali u DCE sustavu su podijeljeni na grupe (groups) i organizacije (organizations). Svaki principal može biti član više grupa, ali ne i više organizacija. Njegovo ime, grupa i pripadnost organizaciji poznati su kao atributi privilegija (privilege attributes), te su uključeni u ulaznicu ([45]).

         Resursi na aplikacijskim poslužiteljima imaju pridružene liste pristupa (access control list – ACL), slično kao u SESAME sustavu. DCE sustav dodjeljuje PAC certifikate (privilege attribute certificate). Ovi certifikati nisu isti kao SESAME PAC certifikati[39]. PS poslužitelj (privilege server) upravlja informacijama o privilegijama. Kad klijent zatraži PAC, PS zatraži Kerberos ulaznicu identificirajući sebe i dodjeljujući klijentu specifičan identifikacijski broj.  Korisnik koristi ulaznicu i svoj DCE autentifikacijski broj za dokazivanje da se nalazi na popisu korisnika koji imaju određene privilegije ([03]).

         U dokumentu [33] autor navodi po njemu glavne nedostatke OSF DCE okružja s gledišta programera. Među ostalim, zamjera im čudne konvencije imenovanja, nekonzistentnost upotrebljavanja definiranih tipova i simboličkih konstanti, lošu i nerazumljivu dokumentaciju (s čestim rupama i kontradiktornostima), grotesknu kompleksnost (npr. funkcije koje se pozivaju sa 17 argumenata). A kao šlag na kraju dodaje da OSF DCE duplicira standarde koji su dobro poznati i već implementirani: npr. uvodi se DTS (Distributed Time Service), dok već postoji NTP (Network Time Protocol).

         DCE je temeljen na Kerberosu V5 i koristi isti protokol za zahtjeve od Kerberos poslužitelja (AS i TGS). No postoji određen broj razlika u implementaciji, što može rezultirati odbijanjem usluga kerberos klijentima. Kerberos V5 poslužitelj ne može zamijeniti DCE Security poslužitelj ([01]).

         U dokumentu [45] daje se kratak pregled i usporedba najpopularnijih sigurnosnih arhitektura (Kerberos, SESAME, DCE, IBM KryptoKnight, DSSA itd).

 

 

9         Bernie – implementacija SESAME arhitekture

         Kao praktični dio uz ovaj rad, razvijena je jednostavna implementacija SESAME arhitekture nazvana Bernie. Treba napomenuti da to nije demonstracija rada SESAME sustava, nego pravi, jednostavan i funkcionalan sigurnosni sustav za autentifikaciju korisnika. Ukoliko nekoga zanima zašto je odabrano upravo to ime, odgovor se nalazi u knjizi “Kad jaganjci utihnu”.

         Bernie se temelji na SESAME protokolu opisanom u [41] i predstavljenom u prijašnjem tekstu. U protokol su unesene sitne izmjenama zbog jednostavnije implementacije. Sustav je predviđen za rad pod Linux 2.x operacijskim sustavom.

Text Box: Slika 16-shema Bernie sustava         Kao i pravi SESAME sustav, Bernie se sastoji od sigurnosnog poslužitelja domene (trenutno podržana samo jedna domena), te aplikacijskih poslužitelja i klijenata koji od njih traže usluge. Da bi klijenti mogli koristiti uslude poslužitelja, moraju se autentificirati Bernie sigurnosnom poslužitelju, koji je  pouzdana treća strana (trusted third party). Predviđeno je da sustav radi na jednom računalu, tj. svi poslužitelji (uključujući i sigurnosni) i klijenti moraju se pokretati na istom računalu. Naime, zbog jednostavnije implementacije na nekim su mjestima ubačene direktne reference na lokalno računalo (localhost, 127.0.0.1) jer je tako bilo jednostavnije nego zahtjevati prave IP adrese. Uz sitnije preinake sustav se može prilagoditi za rad u pravoj mrežnoj okolini (s više umreženih računala).

         Sigurnosni poslužitelj domene (DSS) čine dva poslužitelja: autentifikacijskog (AS) i PAS poslužitelja. KDS poslužitelj nije implementiran jer ualznicu za uslugu, koju bi inače kreirao KDS, kreira klijent kriptirajući ju javnim ključem aplikacijskog poslužitelja čija se usluga želi. Autentifikacijski poslužitelj čeka zahtjeve za autentifikacijom na TCP portu 33333, a PAS na 33334.

         Komandnolinijski korisnički sponzor (user sponsor) nazvan blogin (analogno seslogin) spaja se na AS, a zatim na PAS poslužitelj. Korisnik unosi svoje korisničko ime, ulogu (role) koju želi preuzeti u ovoj sjednici (session) i svoj simetrični tajni ključ duljine jedan znak. Izostavljene su lozinke jer se ključ ionako računa iz lozinke. Autentifikacijski poslužitelj provjerava u bazi podataka korisnika (datoteka users.txt) da li postoji takav korisnik i smije li uzeti željenu ulogu. U tome je razlika u odnosu na pravi SESAME sustav, jer u njemu bi preuzimanje ulogre odobrio PAS poslužitelj, a ne AS. Zbog jednostavnosti je u Bernie sustavu ta zadaća prebačena na AS.

         Ulaznica za dodjelu ulaznica, koja se treba prezentirati KDS poslužitelju da bi on iz nje dobio podatke potrebne za kreiranje ulaznice za uslugu, pohranjuje se u datoteku creds.txt (credentials, vjerodajnice). Uz nju se pohranjuje i korisničko ime, uloga, vrijeme kad ulaznica postaje nevaljana (razdoblje valjanosti) i PPID identifikator (koji identificira radnu stanicu). Razdoblje valjanosti ulaznice ograničeno je na 1 sat, a vremensko okno za komunikaciju između klijenta i poslužitelja na 5 minuta. KDS poslužitelj se zaobilazi u skladu s opisanim protokolom (zato nije ni implementiran) i klijent (nazvan client) kreira sjednički ključ i ulaznicu za uslugu, kriptiranu javnim ključem. Aplikacijski poslužitelj (program appserver, imenom rand_gen), koji čeka zahtjeve na TCP portu 33336,  provjerava ulaznicu te pruža klijentu uslugu. Kao što se na slici vidi, poslužiteljeva PVF i SACM komponenta stopljene su u jedno. Lista pristupa (ACL) koja je osnova kontrole pristupa temeljene na ulogama (RBAC) u ovom je sustavu ostvarena pomoću datoteke rand_gen_acl.txt. U toj su datoteci pohranjeni parovi tipa {uloga, +/-}, koji određuju smije li uloga (+) ili ne smije (-) koristiti pravo pristupa usluzi.

         Klijent proizvoljan broj puta (u intervalu od jedan do deset) postavlja zahtjev poslužitelju za uslugom, koja se sastoji u generiranju jednog slučajnog cijelog broja (u intervali od 0 do 99) i slanja tog broja klijentu, koji ga ispisuje na standardni izlaz. Kad klijent želi završiti komunikaciju, ne šalje poruku SES_CTXT_ABORT, nego spremnik ispunjen nulama. To je znak poslužitelju da klijent nema više zahtjeva.

         Implementacija poslužitelja, točnije njihov kostur[40], temelji se na tekstu [56]. Svi poslužitelji naredbom fork stvaraju kopiju svog procesa kad neki klijent postavi zahtjev za uslugom. Ta kopija zatvara poslužiteljsku mrežnu utičnicu (socket) i uslužuje samo klijenta s kojim je veza uspostavljena. Nakon završetka komunikacije, kopija procesa završava s radom. Na taj način moguće je uslužiti više klijenta koji istovremeno postave zahtjev za uslugom.

         U blogin aplikaciji (koja ima ulogu korisničkog sponzora – user sponsor) integriran je APA klijent u sam kod sponzora. Ne koriste se komponente za potporu (support components) kao što su CSF i PKM jer su te zadaće integrirane u autentifikacijski i PAS poslužitelj, te u klijentske aplikacije (točnije u njihove SACM komponente). Nije implementirana kontrolna (audit) komponenta, nego je ta zadaća integrirana u kod svih aplikacija koje sudjeluju u procesu, tako da svaka ispisuje poruke u svoju kontolnu datoteku. U aplikacijskom klijentu i poslužitelju SACM komponenta je implementirana kao odvojena procedura, a na strani aplikacijskog poslužitelja u nju je integrirana PVF komponenta.

         Za simetrično kriptiranje koristi se XOR algoritam (kao i u originaloj SESAME implementaciji) s ključevima veličine 1 oktet (1 znak). Sažetak poruke (hash) izračunava se sumiranjem vrijednosti svih znakova u poruci . Pečat (seal) se dobiva izračunavanjem sažetka, njegovim dijeljenjem s 10, te se ostatak (0-9) simetrično kriptira zadanim ključem. Za asimetrično kriptiranje koristi se jedinstven javni ključ (E=11, d=3, N=15, RSA algoritam). Potpisivanje poruke vrši se izračunavanjem sažetka (hash) i kriptiranjem sažetka privatnim ključem.

         Prikaz dobivanja javnog i tajnog ključa:

p = 3, q = 5, N = p*q = 15

L(N) = (p-1)*(q-1) = 2*4 = 8

E*d = 1 mod 8

d = 3

z

0

1

2

3

4

z*8+1

1

9

17

25

33

33 : 3 = 11 ® E = 11

         Programi su predviđeni za pokretanje u konzoli. Za vrijeme rada ispisuju poruke o fazama rada i pogreškama na zaslon i u kontrolnu datoteku. Zbog toga je najbolje pokrenuti poslužitelje i klijente svakog u svojom terminalu.

         Redoslijed pokretanja: autentifikacijski poslužitelj, PAS poslužitelj, te blogin. Nakon toga su dobivene vjerodajnice, te AS i PAS poslužitelj mogu ugasiti. Zatim se pokreće aplikacijski poslužitelj, te klijent. Datoteka s vjerodajnicama mora se nalaziti u istom direktoriju u kojem je i klijent, tako da on može učitati potrebne podatke.

9.1        Bernie protokol

         Protokol se temelji na već opisanom SESAME protokolu, a dane su napomene i objašnjenja na mjestima gdje su unesene promjene. {...}BKX označava informacije kriptirane tajnim ključem BKX, [...]BKX zapečaćene tajnim ključem BKX, {...}P kriptirane privatnim ključem, [...]P-1 potpisane privatnim ključem. Oznake su prema [51] i [55].

         Poruke se kreiraju unutar jednog polja znakova, koje se šalje drugoj strani. Kao delimiteri tokena služi dvotočka (:). Općenit format poruke je: IME_PORUKE:token:...:token.

1)US®AS - KRB_AS_REQ: korisnik, uloga, KDS, [AS, ts1]P-1

ts1 označava vremenski biljeg, tj. vrijeme postavljanja zahtjeva. Za dobivanje vremenskih biljega koristi se funkcija time(NULL) koja vraća broj sekundi proteklih od 1.1 1970. do trenutka poziva. Vremenski biljeg služi i kao jednokratna prigodna oznaka (nonce). Certifikati se ne upotrebljavaju, jer svi koriste isti javni i privatni ključ (koji bi se morao inače izvući iz certifikata). Također je zbog jednostavnije implementacije ispušten izazov/odgovor (challenge/response) mehanizam.

2)AS®US - KRB_AS_REP: [korisnik, ts1, ts2, AS]P-1, usr_data, TGTp

        usr_data: {BKUPG, TGS, LUPG, ts1}LKU

        TGTp: {ts1, LUPG, BKUPG, klijentova_IP_adresa}LKAPG

BKUPG označava tajni sjednički ključ koji je generirao AS poslužitelja za komunikaciju između korisnika i PAS poslužitelja, LUPG vrijeme do kojeg je ključ valjan, LKU je dugovažeći korisnikov tajni ključ, a LKAPG dugovažeći tajni ključ koji dijele AS, PAS i KDS poslužitelj. ts2 označava vrijeme slanja odgovora.

3)US®PAS - KRB_PAS_REQ: [TGS, LUPG, ts2, korisnik, uloga]BKUPG, TGTg,    autentifikator

Korisničko ime i uloga predstavljaju tražene privilegijske atribute. Ostali su izostavljeni. Pečati se tajnim sjedničkim ključem.

4)PAS®US – KRB_PAS_REP: [ts2, PAC]BKUPG, PTGT, usr_data

        PAC: [PPID, korisnik, uloga]P-1

        PTGT : {ts1, LXG, BKXG, klijentova_IP_adresa, PPID}LKAPG

        usr_data: {BKXG, ts2, KDS, ts1}BKUPG

         Generirana je nova ulaznica za dodjeluulaznica nazvana PTGT jer joj je dodan PPID.    Generiran je novi sjednički ključ BKXG za komunikaciju klijenta s KDS poslužiteljem.

5)klijent®aplikacijski poslužitelj – SES_INIT_CTXT:

        [[[PPID, korisnik, uloga]P-1, poslužiteljeva_IP_adresa, poslužiteljevo_ime, IKoffset, ulaznica]BKXV, klijentova_adresa,        ts3]IK

        ulaznica: {ts3, LXV, BKXV, klijentova_adresa, PPID}P

Klijent generira novi sjednički ključ BKXV, koji će koristiti on i aplikacijski poslužitelj, te kreira ulaznicu za uslugu kriptiranu javnim ključem, zaobilazeći KDS. IKoffset predstavlja slučajan broj koji se zajedno s novim sjedničkim ključem koristi za generiranje integritetskog ključa IK.

6)poslužitelj®klijent – SES_INIT_CTXT_COMPLETE: [ts3]IK

Vraća se vremenski biljeg iz zahtjeva kao oznaka da se odgovara na taj zahtjev.

         Nakon ovog poslužitelj i klijent razmjenjuju zahtjeve za uslugu i odgovore. Integritetskim ključem štiti se integritet poruke.

klijent®poslužitelj – SES_GIMME_DATA: [redni_broj_zahtjeva]IK

poslužitelj®klijent – SES_DATA_OK: [redni_broj_zahtjeva, odgovor]IK

Kao odgovor šalje se slučajno generiran cijeli broj, koji se ispisuje na zaslon.

9.2        Nedostaci implementacije i moguća poboljšanja

         Iako se Bernie može nazvati prilično dobrom implementacijom protokola, pati od nekoliko problema upravo na razini implementacije. Aplikacija blogin ponekad (iako prilično rijetko, otprilike jednom u dvadeset slučajeva) jednostavno ne obavi posao, nego operacijski sustav javi segmentation fault kad blogin provjerava odgovor dobiven od autentifikacijskog poslužitelja i izbaci core dump. Budući da se koriste pokazivači (pointers), u nekim slučajevima vjerojatno neli “zaluta” i dira nešto što se ne bi smjelo.

         Prilikom komunikacije između aplikacijskog poslužitelja i klijenta ponekad dolazi do greške u komunikaciji (otprilike jednom u petnaest-dvadeset slučajeva). Klijent vjerojatno pošalje poruku u kojoj se nalazi i “memorijsko smeće”, te ga poslužitelj odbija. Moram napomenuti da se ne radi o tome da moja aplikacija odbija uslužiti klijenta, nego sustav zatvara mrežnu utičnicu i klijent završava s radom. Poslužitelj i dalje čeka na klijente, te je dovoljno samo ponovo pokrenuti klijentsku aplikaciju.

         Kriptografija unutar sustava može se poboljšati uključivanjem implementacija DES, IDEA ili Blowfish simetričnih algoritama za kriptiranje umjesto XOR, te uporabom dužih ključeva za (poboljšanu) RSA implementaciju. Kako patent na RSA algoritam istječe 20. rujna ove godine, od tog dana može se koristiti neka već postojeća besplatna implementacija. Iz koda se mogu izdvojiti dijelovi koji imaju kriptografske zadaće i stvoriti kriptografske module, tako se može odabirati kojim se algoritmom želi nešto kriptirati.

         Poboljšanjem kriptografije bazirane na javnim ključevima, postaje moguće uvođenje certifikata kojima bi se sudionici u komunikaciji predstavljali, kao u pravom SESAME protokolu

         Za kodiranje poruka može se uporabiti ASN.1 notacija, koja omogućuje lakše baratanje i bolju zaštitu poruka od mijenjanja.

         Sustav se može proširiti implementiranjem KDS poslužitelja, tako da ulaznice za uslugu izdaje sigurnosni poslužitelj domene i kriptira ih tajnim ključem aplikacijskog poslužitelja, umjesto da ih kreira klijent i kriptira ih javnim ključem poslužitelja.

         Bernie je predviđen za rad na lokalnom računalu, te su u kod unesene direktne reference na računalo na kojem je pokrenut (kao localhost i 127.0.0.1). Uz vrlo male izmjene koda sustav se može prilagoditi za rad u mrežnoj okolini. Na taj način autentifikacijski poslužitelj bi se podigao na jednom računalu, korisnik se spajao s drugog i tražio usluge od poslužitelja na trećem računalu.

         Umjesto stvaranja kopije procesa poslužitelja (naredbom fork) kad neki klijent zatraži uslugu, poslužitelj bi mogao stvoriti novu dretvu koja bi poslužila klijenta (slično rade WWW poslužitelji). POSIX dretve (pthread) bi bile prikladne, jer pthread biblioteka postoji za više računalnih platformi, tako da ovaj sustav ne bi bio vezan samo za Linux platformu.

         Za olakšano sezamiziranje (odnosno bernariziranje) aplikacija može se razviti PAM modul koji omogućuje rukovanje autentifikacijskim procesom na višem nivou, neovisno o upotrijebljenoj shemi. Na taj način izbjegla bi se nužnost direktnog ugrađivanja koda za obradu poruka, jer bi taj posao obavljao modul i PAMiziranoj aplikaciji javio uspjeh ili neuspjeh. Izvorni kod aplikacije ne bi trebalo preuređivati kad se poželi koristiti neka druga autentifikacijska shema.

         Također, ovaj sustav bi se mogao preurediti da ne ispisuje poruke na standardni izlaz u konzoli, nego da otvara prozor u X-Window grafičkom sučelju i ispisuje poruke u taj prozor. Na taj način bilo bi olakšano praćenje poruka.

         Iako se ovoj implemetaciji mogu staviti brojne zamjerke, treba imati na umu da je trenutna verzija samo zametak iz kojeg se može razviti otvoren i vrlo pouzdan sustav, zahvaljujući dobro koncipiranom SESAME protokolu. Zbog svoje jednostavnosti i kratkog vijeka postojanja, Bernie ne mora održavati kompatibilnost unatrag niti je njegov razvoj usmjeren u nekom isključivom smjeru. To ovaj sustav čini pogodnim za vježbe, učenje i eksperimetniranje na području sigurnosti u umreženim sustavima.

 

10   Zaključak

         Tehnologija i znanost munjevitom brzinom grabe naprijed, a najstrelovitije od svih se razvijaju znanosti i tehnologije vezane uz računala. Svaki napredak ima svoje prednosti, nedostatke i nuspojave. U ovom radu kratko su opisana neka od danas popularnih i dostupnih rješenja vezanih uz autentifikaciju i zaštitu od neovlaštenog korištenja.

         Većina današnjih sustava ima korijene u nekadašnjim sustavima koji su bili građeni od strane stručnjaka za druge stručnjake ili vojsku. U tim sustavima nije bila toliko pridavana pažnja inkorporiranju jakih i strogih sigurnosnih mehanizama u sustave. Koncepti su se oslanjali na uvjerenja da kolege neće namjerno otežavati međusobni rad, te da vojska ima odgovarajuća rješenja i metode za zaštitu pristupa i sprečavanje korištenja uređaja od strane nepoželjnih osoba.

         U današnjem svijetu, koji postaje globalno selo, kad se informacijski sustavi uvlače duboko u svakodnevni rad, više se ne može vjerovati u dobronamjernost korisnika sustava. Zbog očuvanja kompatibilnosti s prijašnjih verzijama, sustavi često pate od naslijeđenih nedostatatka. Zbog nedostataka i propusta u arhitekturama i implementacijama ili zbog “dječijih bolesti” novih sustava, svjedoci smo svakodnevnih napada i zlouporaba računala u svrhe za koje ih njihovi tvorci nisu namijenili. Ljudi padaju u iskušenja da učine nešto štetno ili neovlašteno, jednostavno zato što su u prilici ili da se dokažu. Zbog toga se, nažalost, moraju odvojiti određeni materijalni i humani resursi s ciljem zaštite sustava, umjesto da se i ta sredstva upotrijebe za razvoj novih sustava i još brži napredak.

         Danas, kad je sve mreža i do svega se može doći preko računalne mreže, više nije moguće reći da se napadi mogu zanemariti, pogotovo ako se mjere u tisućama ili milijunima dolara. U umreženim okolinama, dok distribuirano računarstvo uzima sve više maha, kontrola pristupa i autentifikacija korisnika postaju conditio sine qua non. Autentifikacijski mehanizmi razvijani su sa željom da se spriječi destruktivno ponašanje i neovlašteno iskorištavanje. Krivci će biti kažnjeni, jer se nedvojbeno može utvrditi tko su oni. Nevini korisnici bit će zaštićeni, a uljezima se neće dopustiti neovlašteno korištenje usluga sustava.

         Autentifikacijski mehanizmi također imaju svojih mana i ne štite od svih opasnosti u mrežnom okružju, jer su dizajnirani s namjerom da se suprotstave samo određenim opasnostima, usredotočuju se na određene aspekte. Prioriteti se mijenjaju s vremenom, nastaju nove prijetnje i sustavi evoluiraju ili ih se odbacuje. Svaki nudi bolji rezultat u nekom području od svih ostalih, no niti jedan nije savršen. Trenutno se kao najbolji i najsvestraniji čini SESAME, čije naslijeđe potječe od već veteranskog, no pomlađenog i još uvijek neumoljivog Kerberosa. Na pitanje koje zaštitne mehanizme i kada upotrijebiti, ne može se dati univerzalan odgovor. Kao i kad su oni nastajali, uvijek postoje prioriteti i nešto što je važnije od ostalog. Uvijek postoji period “dječijih bolesti” i privikavanja, a moguć je i pogrešan izbor. Jedino rješenje je informirati se, učiti na prijašnjim iskustvima i ulagati, jer se ulaže malo sada da se ne bi puno izgubilo u budućnosti.

 

 

 

11   Leksikon/rječnik pojmova

accounting – (manipulacija korisničkim računima, [04]); obračunavanje korištenja resursa    dodijeljenih određenom klijentu

APA Client– (Authentication Privilege Attribute Client) aplikacijsko programsko sučelje (API)          pomoću čijih poziva US komunicira sa DSS poslužiteljem da bi autentificirao korisnika i     dobio vjerodajnice, dio klijenta u SESAME arhitekturi

authentication [41]– (autentifikacija); utvrđivanje istinitosti deklariranog identiteta principala

auth. header -  (aut. zaglavlje); slog koji sadrži Kerberos ulaznicu i autentifikator koji se moraju     predočiti poslužitelju u sklopu autentifikacijskog procesa

auth. path –  (aut. staza); niz područja (realm) kroz koja se prolazi u autentifikacijskom procesu    kad se komunicira između dva područja

authenticator – (autentifikator); slog koji sadrži informaciju za koji se može pokazati da je    nedavno generirana koristeći sjednički ključ poznat samo poslužitelju i klijentu

authorization– (autorizacija); proces određivanja smije li klijent koristiti neku uslugu, kojim    objektima smije pristupati i odobreni način pristupa za svaki od njih

ASN.1 – Abstract Syntax Notation One; notacija za opis poruka, a poruke su zaštićene od mijenjanja jer se u njih ubacuje i tip i duljina poruke, tako da se rezanje ili ubacivanje može      otkriti

capability – ovlaštenje koji dozvoljava donositelju (bearer) pristup određenim objektima ili usluzi.   U Kerberos sustavima to može biti ulaznica čije je korištenje ograničeno sadržajem autorizacijskog polja (no ne sadrži mrežnu adresu), zajedno sa sjedničkim ključem       potrebnim da bi se ulaznica koristila

challenge/response – shema u kojoj jedna strana šalje drugoj broj ili string koji predstavlja izazov          (challenge). Druga strana nešto mijenja u tome (neke znamenke ili znakove) prema         određenoj shemi i vraća odgovor (response) prvoj strani.

client – (klijent); proces koji omogućuje korištenje mrežne usluge u korist korisnika (u nekim          slučajevima sam poslužitelj može biti klijent nekom drugom poslužitelju)

credential – (vjerodajnica); zajedničko ime za ulaznice i autentifikatore, često se ovim imenom      naziva i samo ulaznica plus tajni sjednički ključ nužan za uspješno korištenje ulaznice u         autentifikacijskoj razmjeni; u Linux-PAM-u se ovim izrazom nazivaju neke karakteristike/          atributi koje PAM može donijeti o korisniku nakon uspješne autentifikacije, npr. ulaznice u          obliku varijabli okoline i sl. UID i    GID se ne smatraju PAM vjerodajnicama, nego je za        njihovu direktnu dodjelu odgovorna aplikacija (nazivaju se user-credentials)

credentials cache – (spremište vjerodajnica); lokacija gdje se spremaju vjerodajnice, obično         datoteka, no ponekad neko mjesto u memoriji računala

DSS – (Domain Security Server) SESAME sigurnosni poslužitelj za domenu (područje), analogno         Kerberos poslužitelju

host – (domaćinsko ili radno računalo); računalo kojem se pristupa preko mreže; udaljenim   (remote) se može pristupiti samo preko drugog računala (elektronički), ne direktno

KDC, Key Distribution Center –  mrežna usluga koja dodjeljuje ulaznice i privremene sjedničke         ključeve ili instanca te usluge ili poslužitelj na kojem se izvršava. KDC usluge obuhvaćaju i    inicijalne ulaznice i zahtjeve za ulaznicom za dodjelu ulaznice; sinonim za autentifikacijski       poslužitelj; ponekad se ovim imenom naziva cijeli Kerberos poslužitelj (AS + TGS), no to je posebno naglašeno u takvim slučajevima

KDS – (Key Distribution Server) u SESAME arhitekturi poslužitelj koji kreira sjedničke ključeve i        ulaznice za uslugu koju će koristiti klijent, sličan Kerberos TGS poslužitelju

keytab – datoteka (key table) u kojoj su pohranjeni ključevi koje radno računalo (host) ili usluga     (service) koristi onako kako korisnici koriste svoje lozinke

NTP – Network Time Protocol; kriptografski ojačan protokol za vremenske usluge. Omogućuje   velikim mrežama sinkronizaciju programskih satova uz pomoć nekoliko vrlo točnih fizičkih      satova ([24])

PAS – (Privilege Attribute Server) dio SESAME DSS sigurnosnog poslužitelja, upravlja RBAC   mehanizmima

principal – (principal); jednoznačno imenovana klijentska ili poslužiteljska instanca koja sudjeluje    u mrežnoj komunikaciji; entitet koji participira u autentifikaciji; obično korisnik ili instanca         mrežne usluge na određenom računalu ([03]); Kerberos klijent (nazvan tako da bi se razlikovao od klijenata drugih usluga); općenito sastavljen od tri dijela ([21]):

         primary – (primarni) prvi dio Kerberos principala, identificira individualne korisnike ili tip                        usluge; za korisnike je to njihovo korisničko ime

         instance – (instanca) – informacija koja kvalificira primarni, može biti iskorištena za opis                       namjere korištenja odgovarajućih vjerodajnica; ako principal predstavlja računalo                       (host), instanca je njegovo ime

         realm -  (područje); logička mreža (network) koju opslužuje jedna Kerberos baza i niz                           Kerberos poslužitelja (jedan glavni a ostali pomoćni), po konvenciji se imena daju                         pisana velikim slovima da se razlikuju od običnih internet domena

principal identifier - (identifikator principala); ime korišteno da bi se jednoznačno identificirali      različiti pojedini principali

proxy – (zamjena, ovlaštenje); token koji dozvoljava nekome da radi s privilegijama principala koji mu je dodjelio to ovlaštenje

PAC – (Privilage Attribute Certificate) certifikat koji se dodjeljuje SESAME klijentu, te se uz      njegovu pomoć vrši autentifikacija, sadržava privilegijske atribute (privilege attributes):   razdoblje valjanosti certifikata, uloga (role) itd.

PVF – poslužiteljska komponenta koja provjerava klijentske PAC certifikate

RBAC – (Role Based Access Control) kontrola pristupa temeljena na ulogama: korisnici uzimaju          određene uloge (roles) prilikom prijave na sustav, te im se daje pristup resursima u ovisnosti   koju ulogu su uzeli; neki korisnik može imati više uloga, no tijekom jedne prijave za rad (log    on) može imati samo jednu ulogu

SACM - (Secure Association Context Manager) komponenta u SESAME arhitekturi koja je      implementirana   kao biblioteka subrutina, a omogućuje autentifikaciju podataka i        (opcionalno) njihovu tajnost u komunikaciji između klijenta i poslužitelja.

seal – (pečat); vrsta kruptografske zaštite koja služi za zaštitiu slog koji sadrži nekoliko polja tako   da se polja ne mogu pojedinačno mijenjati bez znanja enkripcijskog ključa ili bez ostavljanja         tragova; izračunava iz poruke u jasnom tekstu i ključa (kojim se pečati), te se obično stavlja     na kraj poruke

server – (poslužitelj); principal koji osigurava neki resurs mrežnim klijentima

service – (usluga); resurs pružen mrežnim klijentima, obično postoji više poslužitelja koji nude        svoje usluge

session key – (sjednički ključ); privremeni simetrični enkripcijski ključ koji koriste dva principala, ograničenog životnog vijeka na trenutnu sjednicu

signature – ([digitalni] potpis); poruka se potpisuje tako da se propusti kroz hash algoritam, te se sažetak kriptira (najčešće) tajnim ključem (P-1) iz para javni/tajni ključ ([52])

single sign-on system – sustav koji traži početnu potvrdu korisničkog identiteta, no sve ostale      autentifikacijske poslove provodi automatski; u ovakvom sustavu korisnik treba upisati svoju     lozinku samo jednom, na početku sjednice; Kerberos je primjer ovakvog sustava

stash file – datoteka koja omogućuje autentifikacijskom poslužitelju da se autentificira alatima za   rad s          Kerberos bazom, kao što je kadmin

sub-session key – (podsjednički ključ); privremeni  enkripcijski ključ korišten u komunikaciji         između dva principala (izabran i razmijenjen koristeći sjednički ključ)

ticket – (ulaznica); slog (zapis) koji pomaže klijentu da se autentificira poslužitelju (prezentirano     zajedno sa svježim autentifikatorom); sadrži njegov identitet, sjednički ključ, vremenski     biljeg (timestamp) i neke druge informacije, sve zapečaćeno koristeći poslužiteljev tajni    ključ.

trusted host – pouzdano domaćinsko računalo

user sponsor, US – (korisnički sponzor) aplikacija koja omogućuje autentifikaciju korisnika udaljenoj usluzi

 

12   Literatura

[01] B. Jaspan: “Kerberos Users' Frequently Asked Questions”, v1.14, 15. rujna 1995. ftp://athena.dist.mit.edu/pub/kerberos/Kerberos.faq

[02] B. Bryant: “Designing an Authentication System: a Dialogue in Four Scenes”, DRAFT, veljača 1988, ftp://athena.dist.mit.edu/pub/kerberos/doc/dialogue.ps

[03] J.T. Kohl, B.C. Neuman, T. Ts’o: “The Evolution of the Kerberos Authentication Service”, (stavljeno na ftp server 18. kolovoza 1992) ftp://athena.dist.mit.edu/pub/kerberos/doc/krb_evol.ps

[04] D. Davis, R. Swick: “Workstation Services and Kerberos Authentication at Project Athena”, 17. ožujka 1989, ftp://athena.dist.mit.edu/pub/kerberos/doc/krbdoc.ps

[05] M.A. Sirbu, J. Ching-I Chuang: “Distributed Authentication in Kerberos Using Public Key Criptography”, http://www.cs.cmu.edu/afs/andrew.cmu.edu/inst/ini/www/Netbill/pubs/pkda.html

[06] R.Bagwill et al.: “Security in Open Systems”, NIST Special Publication 800-7, srpanj 1994, http://www-08.nist.gov/nistpubs/800-7/main.html

[07] S.P. Miller, B.C. Neuman, J.I. Schiller, J.H. Saltzer: “Kerberos Authentication and Authorization System”, Project Athena tehnical plan, section E.2.1, 27. listopada 1988, ftp://athena.dist.mit.edu/pub/kerberos/doc/techplan.ps

[08] J.G. Steiner, C. Neuman, J.I.Schiller: “Kerberos: An Authentication Service for Open Network Systems”, 30. ožujka 1988, ftp://athena.dist.mit.edu/pub/kerberos/doc/usenix.ps

[09] J. Kohl, B.C. Neuman: “The Kerberosä Network Authentication Service (V5)”, INTERNET DRAFT, 1. listopada 1992, ftp://athena.dist.mit.edu/pub/kerberos/doc/v5rev5-1.ps

[10] J. Danielsson, A. Westerlund: “KTH_KRB: Kerberos 4 from KTH, edition 0.9.9, for krb4-0.9.9”, 17. lipnja 1999, http://docs.linux.cz/soft/kth-krb/kth-krb_1.html

[11] A. G. Morgan: “The Linux-PAM System Administrators' Guide”, v0.71, 8. studenog 1999, ftp.lip6.fr/pub/linux/pam/distrib/Linux-PAM-html/pam.html

[12] A. G. Morgan: “The Linux-PAM Application Developers'  Guide”, v0.71, 8. studenog 1999, ftp.lip6.fr/pub/linux/pam/distrib/Linux-PAM-html/pam_appl.html

[13] A. G. Morgan: “The Linux-PAM Module Writers' Guide”, v0.71, 8. studenog 1999, ftp.lip6.fr/pub/linux/pam/distrib/Linux-PAM-html/ pam_modules.html

[14] B.C. Neuman, T. Ts’o: “Kerberos: An Authentication Service for Computer Networks”, USC/ISI Technical Report number ISI/RS-94-399, IEEE Communications Magazine, Volume 32, Number 9, pages 33-38, September 1994, http://nii.isi.edu/publications/kerberos-neuman-tso.html
[15] B. S. Kaliski Jr.: “A Layman’s Guide to a Subset of ASN.1, BER and DER”, 1. studenog 1993., ftp://ftp.rsa.com/pub/pkcs/ps/layman.ps

[16] V. Samar, R. Schemers: “Unified Login With Pluggable Authentication Modules (PAM)”, listopad 1995., OSF RFC 86.0, dokumentacija uz instalirani Linux-PAM paket

[17] S.M. Bellowin, M. Merrit: “Limitations of the Kerberos Authentication System”, USENIX, zima 1991, Dallas, http://research.att.com/dist/internet_security/kerblimit.usenix.ps

[18] N. Dahyabhai: “The Linux-at-NCSU FAQ/HOWTO”, DRAFT 0.80, 5. srpnja, 1998, http://thermo.stat.ncsu.edu/~nalin/FAQ/FAQ_NCSU.html

[19] E.J. Berkenbilt, B.B. Manganis, A. Dvornik: “Inessential AFS”, v2.00, 14. rujna 1992, http://web.mit.edu/afs/sipb.mit.edu/project/doc/afs/html/afs-new.html

[20] K. Hornstein: “Kerberos FAQ”, v1.11 , 23. rujna 1999.

[21] “KerbNet System Administrator’s Giude”, verzija 1.2, 31. ožujka 1997, http://www.cygnus.com

[22] D. Engert: “SSLK5 - SSL Authentication for Kerberos V5”, 4. travnja 1998., ftp://achilles.ctd.anl.gov/pub/README.sslk5

[23] A.G.Morgan: “Pluggable Authentication Modules”, 6. listopada 1999., draft-morgan-pam-06.txt

[24] D. Davis, D. E. Geer, T. Ts’o: “Kerberos Security With Clocks Adrift: History, Protocols and Implementation”, 19. rujna 1995, http://world.std.com/~dtd/synch/synch.ps

[25] “KerbNet UNIX User’s Guide”, verzija 1.2, 14. svibnja 1997, http://www.cygnus.com

[26] RFC1510, J. Kohl i C. Neuman, rujan 1993, http://www.faqs.org/rfcs/rfc1510.htm

[27] C. Neuman, B. Tung, J. Wray, A. Medvinsky, M. Hur, J. Trostle: “Public Key Cryptography for Initial Authentication in Kerberos”, nadopuna RFC1510, 1997, http://www.isi.edu/gost/info/pk_init/pk_init_03.txt

[28] B.C. Neuman, S.G. Stubblebine: “A Note on Use of Timestamps as Nonces”, Operating Systems Review, 27(2):10-14, travanj 1993., ftp://prospero.isi.edu/pub/papers/security/ntn.ps.gz
[29] S. Garfinkel, G. Spafford: “Practical UNIX Security”, ISBN 0-937175-72-2

[30] "The Three Myths Of Firewalls", http://web.mit.edu/kerberos/www/firewalls.html

[31] L. Budin: Predavanja iz “Operacijskih Sustava II” na FER-u, ak. god. 1999./2000.

[32] M. Žagar: Predavanja iz “Otvorenog računarstva” na FER-u, ak. god 1999./2000.

[33] B. Ediger: “10 Reasons why OSF DCE sucks”, 1999., http://www.cnn.net/~bediger/anti_dce.html

[34]P. Blackburn: “AFS distributed filesystem FAQ”, verzija 1.113, 26. siječnja 2000., http://www.angelfire.com/hi/plutonic/afs-faq.html

[35]”How to Kerberize Your Site”, http://www.epm.ornl.gov/~jar/HowToKerb.html

[36] B.Tung: “The Moron’s Guide to Kerberos”, verzija 1.2.2., 19. prosinca 1996., http://gost.isi.edu/brian/security/ kerberos.html

[37] “Web Authorization/Authentication”, listopad 1997., http://www.brown.edu/Facilities/CIS/ATGTest/ Infrastructure/Web_Access_Control/GoalsOptions_ver2.html

[38] D.Davis: “Kerberos Plus RSA for World Wide Web Security”, 3. kolovoza 1995., http://world.std.com/~dtd/rsatkt/rsatkt3.ps

[39] “Project Minotaur: Kerberizing the Web”, http://andrew2.andrew.cmu.edu/minotaur/overview.html

[40] Daniel Henninger: “Apache Kerberos”, 13. rujna 1999., http://stonecold.unity.ncsu.edu/software/mod_auth_kerb/index.html

[41] M.Vandenwauver, R.Govaerts, J.Vandewalle: “Security of Client-Server Systems”, , Information Security - from Small Systems to Management of Secure Infrastructures, J.P. Eloff and R. von Solms, Ed., IFIP Press, May 1997, pp. 39-54., http://www.esat.kuleuven.ac.be/cosic/sesame/papers/wg11.2-7/index.html

[42] N. Itso: “Design of Secure Hardware Integration with Kerberos V5”, 8. siječnja 1999.,

http://www-personal.engin.umich.edu/~itoi/k4758/Cartel-k4758/Cartel-k4758.ppt

[43] P.Ashley, M.Vandenwauver, B.Boom: “A Uniform Approach to Securing Unix Applications Using SESAME”, Proceedings of the 3rd ACISP Conference - LNCS 1438, 1998, pp. 24-35, http://www.esat.kuleuven.ac.be/cosic/sesame/papers/acisp98.pdf

[44] N.Itoi, P.Honeyman: “Pluggable Authentication Modules for Windows NT”, 4. kolovoza 1998., http://www-personal.engin.umich.edu/~itoi/ni_pam_usenix.pdf

[45] P.Ashley, B.Boom: “A Survey of Secure Multi-Domain Distributed Architectures”, FIT Technical Report, 1997, FIT-TR-97-08., http://www.esat.kuleuven.ac.be/cosic/sesame/papers/arch-overview.pdf

[46] P.Ashley: “Authorization For A Large Heterogeneous Multi-Domain System”, Australian Unix and Open Systems Group National Conference, 1997, http://www.esat.kuleuven.ac.be/cosic/sesame/ papers/auugnat97-2.pdf

[47] M. Vandenwauver, R. Govaerts, J. Vandewalle: “Overview of Authentication Protocols”, Proceedings 31st Annual IEEE Carnahan Conference on Security Technology, pages 108-113, 1997., http://www.esat.kuleuven.ac.be/cosic/sesame/papers/carnahan.pdf

[48] K. Beznosov: “CORBASEC Frequently Asked Questions and Answers”, 18. lipnja 1999., http://cadse.cs.fiu.edu/corba/corbasec/faq/multi-page/

[49] M. Persson. U. Lindbergh: “Kerberos and SESAME”, 9. srpnja 1999., http://www.esat.kuleuven.ac.be/cosic/sesame/matsulf/kerberos.html

[50] G.Gaskell, P.Ashley, M.Vandenwauver, J.Claessens: “Intranet Security Technologies – SESAME or SSL?”, Proceedings of Australian Unix and Open Systems Group (AUUG) National Conference, Sydney, Australia, 1998, pp. 133-142., http://www.esat.kuleuven.ac.be/cosic/sesame/papers/auug98.pdf

[51] M.Vandenwuver, R.Govaerts, J.Vandewalle: “Public Key Extensions Used in SESAME V4”, Presented at Public Key Solutions PKS'97, travanj 1997., http://www.esat.kuleuven.ac.be/~vdwauver/pks97/pks97.html

[52] M.Vandenwuver, R.Govaerts, J.Vandewalle: “How Role Based Access Control is Implemented in SESAME”, Proceedings of the 6-th Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, pages 293-298, IEEE Computer Society Press, 1997., http://www.esat.kuleuven.ac.be/cosic/ sesame/papers/wetice97.pdf

[53] P.Ashley, B.Boom: “An Implementation of the SESAME Security Architecture for Linux”, Australian Unix and Open Systems Group Technical Conference, 1997, http://www.esat.kuleuven.ac.be/cosic/sesame/ papers/auugqld97.pdf

[54] B.Boom, P.Ashley: “A SESAME Linux Environment”, Australian Unix and Open Systems Group Technical Conference, 1998., http://www.esat.kuleuven.ac.be/cosic/sesame/papers/auug98-1.pdf

[55] P.V.McMahon: “SESAME V2 Public Key and Authorisation Extensions to Kerberos”, 1994, ftp://ftp.enst.fr/pub/sesame/seskrb.ps.gz

[56] “BSD Sockets”, http://www.ecst.csuchico.edu/~chafey/prog/sockets/sinfo1.html


[1] usporediti sa zahtjevima prema distribuiranim autentifikacijskim sustavima opisanim u prethodnom poglavlju

[2] [07]

[3] [09]

[4] [03]; [20]

[5] [26], poglavlje 2.2.

[6] [07]

[7] [07]

[8] [09]

[9] [20]

[10] R. M. Needham, M. D. Schroeder. “Using Encryption for Authentication in Large Networks of Computers”, Communications of the ACM, vol. 21 (12), pp. 993-99

[11] prema [41], te [14], [08], [06], [26]

[12] razlikovati korisnika (u) od klijenta (c) – korisnik može koristiti bilo koji klijentski stroj (koji ima svoju adresu)

[13] X Window, ne X-Windows

[14] prema [15]

[15] [42]

[16] [29]

[17] korisnici često kao lozinke uzimaju smislene pojmove, poput imena i sl. te je pogađanje olakšano

[18] [37]

[19] protokol za upravljanje i prijenos hiperteksta (stranica opisanih HTML jezikom) preko Interneta od poslužitelja do klijenta, koristi TCP i IP protokole ([32])

[20] [39]

[21] [40]

[22] prema [11]

[23] prema [13]

[24] prema [44]

[25] prema [12]

[26] [43]

[27] “primary principal” je termin ECMA komisije za korisnikovu radnu stanicu; korisnik je “secondary principal” ([55])

[28] [41]

[29] više o tome se može naći u [52]

[30] razmjena poruka prema [41]; iako je u tom članku navedeno da je opisan međudomenski (interdomain) slučaj, radi se o unutardomenskom. Vjerojatno lapsus calami (prilikom prijepisa), jer je u [55] ovakva razmjena poruka označena kao unutardomenska

[31] u [41] se u TGT u koraku 2 nalazi i PPID koji predstavlja “broj korisnikovog certifikata”, no koraku 3 se  TGT šalje no u njoj nije uključen taj podatak. Kako ni korisnik ni klijent ne znaju tajni ključ AS poslužitelja, ne mogu izmijeniti poruku. PPID kasnije generira PAS poslužitelj. Zbog toga (nalazeći opravdanje u opisu protokola u [55]) izostavio sam taj diskutabilni podatak iz TGT

[32] [54]

[33] [49]

[34] [50]

[35] [41]

[36] kartica sadrži Java Virtual Machine (koji izvršava programe) i memoriju za dodatne podatke ([32])

[37] Nepouzdani bespojni protokol: ne brine se jesu li paketi stigli na drugu stranu i ne slijedi retansmisija ako su izgubljani (za razliku od TCP-a), obično se koristi kad se šalje malena količina podataka, npr. poruke ([32])

[38] pozivi funkcija s klijenta u nekom predefiniranom programskom jeziku se šalju poslužitelju na mreži koji izvrši funkciju i vrati rezultat klijentu

[39] vidi [55] za usporedbu

[40] kako stvoriti poslužiteljsku mrežnu utičnicu, kako prihvatiti zahtjev klijenta i kako zahtjevati uslugu od poslužitelja

[41] uglavnom prema [26]