AUTENTIZACE A AUTORIZACE UŽIVATELE

ˇ Í TECHNICKE´ V BRNEˇ VYSOKE´ UCEN BRNO UNIVERSITY OF TECHNOLOGY

ˇ ÍCH TECHNOLOGIÍ FAKULTA INFORMACN ˇ ÍCH SYSTEM ´ ´ U ˚ USTAV INFORMACN FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS

ˇ AUTENTIZACE A AUTORIZACE UZIVATELE ˇ ÍTACOV ˇ ´ V POC YCH SÍTÍCH NOVE´ GENERACE

´ DIPLOMOVA´ PRACE MASTER’S THESIS

´ AUTOR PRACE AUTHOR

BRNO 2007

ˇ Bc. RADEK PRIBYL

ˇ Í TECHNICKE ´ V BRNE ˇ VYSOKE´ UCEN BRNO UNIVERSITY OF TECHNOLOGY

ˇ ÍCH TECHNOLOGIÍ FAKULTA INFORMACN ˇ ÍCH SYSTEM ´ ´ U ˚ USTAV INFORMACN FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS

ˇ AUTENTIZACE A AUTORIZACE UZIVATELE ˇ ÍTACOV ˇ ´ V POC YCH SÍTÍCH NOVE´ GENERACE USER AUTHENTICATION AND AUTHORISATION FOR NEW GENERATION NETWORKS

´ DIPLOMOVA´ PRACE MASTER’S THESIS

´ AUTOR PRACE

ˇ Bc. RADEK PRIBYL

AUTHOR

´ VEDOUCÍ PRACE SUPERVISOR

BRNO 2007

ˇ Ing. PETR MATOUSEK, Ph.D.

Abstrakt Tato práce popisuje zp˚ usoby autentizace a autorizace uˇzivatele pomoc´ı d˚ uvˇeryhodného serveru. Je zde rozebrán systém Kerberos, kter´ y slouˇz´ı jako inspirace pˇri návrhu vlastn´ıho autentizaˇcn´ıho schéma. Na konkrétn´ım pˇr´ıkladu aplikac´ı jsou analyzovány programové vrstvy a jejich rozhran´ı zajiˇstuj´ıc´ı autentizaci a autorizaci uˇzivatele. V dokumentu je navrˇzen a popsán model autentizaˇcn´ıho mechanismu. Tento mechanismus je implementován do komunikace mezi emailov´ ym klientem a imap serverem.

Kl´ıˇ cov´ a slova kryptografie, autentizace, autorizace, AAA schéma, systém Kerberos, GSSAPI, SAUP protokol, Radius

Abstract This document describes methods of user authentication and authorisation via a trusted server. There is analysis of the system Kerberos, which is used as an inspiration for desing of a new authentication scheme. There are analysed programming layers and interfaces for specific applications ensuring user authentication and authorisation. The document contains a design and detailed description of a new authentication scheme. This scheme is implemented into the communication between email client and imap server.

Keywords cryptography, authentication, authorisation, AAA scheme, system Kerberos, GSSAPI, SAUP protocol, Radius

Citace Radek Pˇribyl: Autentizace a autorizace uˇzivatele v poˇc´ıtaˇcov´ ych s´ıt´ıch nové generace, diplomová práce, Brno, FIT VUT v Brnˇe, 2007

Autentizace a autorizace uˇ zivatele v poˇ c´ıtaˇ cov´ ych s´ıt´ıch nov´ e generace Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem tuto diplomovou práci vypracoval samostatnˇe pod veden´ım Ing. Petra Matouˇska ....................... Radek Pˇribyl 22. kvˇetna 2007

Podˇ ekov´ an´ı T´ımto bych chtˇel podˇekovat Ing. Petru Matouˇskovi za pomoc a rady, které mi poskytl pˇri ˇreˇsen´ı dilpomové práce.

c Radek Pˇribyl, 2007.

Tato pr´ ace vznikla jako ˇskoln´ı d´ılo na Vysokém uˇcen´ı technickém v Brnˇe, Fakultˇe informaˇcn´ıch technologi´ı. Pr´ ace je chr´ anˇena autorským z´ akonem a jej´ı uˇzit´ı bez udˇelen´ı opr´ avnˇen´ı autorem je nez´ akonné, s výjimkou z´ akonem definovaných pˇr´ıpad˚ u.

Obsah ´ 1 Uvod

3

2 Kryptografie 2.1 Symetrická ˇsifra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Asymetrická ˇsifra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 4 5

3 Autentizace a autorizace 3.1 Autentizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Zp˚ usoby autentizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Autorizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 6 6 7

4 AAA sch´ ema 4.1 Radius . . 4.2 Diameter 4.3 EAP . . . 4.4 802.1x . . 4.5 Shrnut´ı .

. . . . .

8 9 11 11 13 15

5 Autentizace pomoc´ı syst´ emu Kerberos 5.1 Protokol Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16 16

6 Programov´ e n´ astroje pro autentizaci 6.1 Aplikace vybrané pro anal´ yzu . . . . . . . . 6.2 Instalace a konfigurace systému pro anal´ yzu 6.3 Kerberizované aplikace . . . . . . . . . . . . 6.4 Programové rozhran´ı aplikac´ı . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

20 20 21 22 23

7 Model autentizace a autorizace uˇ zivatele v glob´ aln´ıch s´ıt´ıch 7.1 Poˇzadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Typy model˚ u komunikace . . . . . . . . . . . . . . . . . . . . . 7.3 Návrh modelu komunikace . . . . . . . . . . . . . . . . . . . . . 7.4 Návrh protokolu SAUP - Single Authentication Protocol . . . . 7.5 Vytvoˇren´ı ˇsifrovac´ıho kl´ıˇce kAB . . . . . . . . . . . . . . . . . . 7.6 Typy zpráv protokolu SAUP . . . . . . . . . . . . . . . . . . . 7.7 Protokol Radius . . . . . . . . . . . . . . . . . . . . . . . . . . 7.8 Model systému v praxi . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

29 29 30 31 32 34 35 37 37

1

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

8 Implementace 8.1 Pouˇzit´ y software . . . . . ´ 8.2 Uprava software . . . . . . 8.3 Knihovna libdip service.so 8.4 Instalace . . . . . . . . . . 8.5 Konfigurace . . . . . . . .

. . . . .

39 39 39 41 42 43

9 Bezpeˇ cnost syst´ emu 9.1 Bezpeˇcnost protokolu SAUP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 Kvalita implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45 45 46

10 Z´ avˇ er

47

A Instalace

49

B Konfigurace postfix, imap, Kerberos, pine

53

C GSSAPI Autentizace

57

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

2

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

Kapitola 1

´ Uvod V souˇcasné dobˇe je kladen stále vˇetˇs´ı d˚ uraz na zabezpeˇcen´ı systém˚ u a komunikace pˇred u ´toˇcn´ıky. V minulosti byla proto do systém˚ u zavedena autentizace a autorizace uˇzivatel˚ u. Ve vˇetˇsinˇe pˇr´ıpad˚ u se ale uˇzivatel pˇrihlaˇsuje k systému pˇres poˇc´ıtaˇcovou s´ıt’. Proto mus´ı b´ yt tato komunikace mezi uˇzivatelem a serverem, ke kterému uˇzivatel pˇristupuje, zabezpeˇcen´ a. ´ Uroveˇ n zabezpeˇcen´ı m˚ uˇze b´ yt na r˚ uzn´ ych vrstvách komunikaˇcn´ıch protokol˚ u. Pokud ovˇsem ned˚ uvˇeˇrujeme zp˚ usobu zabezpeˇcen´ı protokol˚ u niˇzˇs´ıch vrstev, mus´ıme implementovat zabezpeˇcen´ı komunikace na aplikaˇcn´ı u ´rovni. V praxi je vˇetˇsinou v aplikac´ıch implementováno v´ıce druh˚ u mechanism˚ u pro zp˚ usob autentizace a zabezpeˇcen´ı pˇrenosu dat. C´ılem diplomové práce je návrh nového mechanismu autentizace a autorizace uˇzivatele vyuˇz´ıvaj´ıc´ı d˚ uvˇeryhodn´ y server pro ovˇeˇren´ı totoˇznosti uˇzivatele. Dalˇs´ım u ´kolem je tento mechanismus implementovat a ukázat jeho funkˇcnost. Diplomová práce je rozdˇelena do dvou velk´ ych celk˚ u. V prvn´ım jsou zahrnuty kapitoly, které slouˇz´ı jako teoretick´ y základ k pochopen´ı problematiky autentizace a autorizace uˇzivatele. V tomto celku jsou popsány také protokoly a systémy, které realizuj´ı autentizaci uˇzivatele pomoc´ı d˚ uvˇeryhodného serveru. V tˇechto protokolech jsem hledal inspiraci pro druhou ˇcást diplomové práce. Druhá ˇcást obsahuje návrh nového schématu pro autentizaci uˇzivatele a jeho implementaci. Dále je zde také na konkrétn´ım pˇr´ıkladu popsán zp˚ usob, jak´ ym ˇreˇs´ı implementaci autentizaˇcn´ıch mechanism˚ u stávaj´ıc´ı aplikace. Tato práce navazuje na Semestráln´ı projekt, v rámci kterého jsem studoval zp˚ usoby autentizace a autorizace uˇzivatele. Do diplomové práce jsem pˇrevzal ˇcásti Semestráln´ıho projektu, které popisuj´ı teoretick´ y základ pro danou problematiku a kter´ ymi jsem se inspiroval pˇri návrhu vlastn´ıho autentizaˇcn´ıho schématu. Jsou to kapitoly zab´ yvaj´ıc´ı se kryptografi´ı (kapitola 2), autentizac´ı a autorizac´ı uˇzivatele (kapitola 3), AAA schématem (kapitola 4) a protokolem Kerberos (kapitola 5).

3

Kapitola 2

Kryptografie Kryptografie neboli ˇsifrován´ı je nauka o metodách utajován´ı obsahu zpráv pˇrevodem do podoby, která je ˇcitelná jen se speciáln´ı znalost´ı. Slovo kryptografie pocház´ı z ˇreˇctiny krypt´ os skryt´ y a gr´ aphein znamená psát. Nˇekdy je pojem obecnˇeji pouˇz´ıván pro vˇedu o ˇcemkoli spojeném se ˇsiframi jako alternativa k pojmu kryptologie. Kryptologie zahrnuje kryptografii a kryptoanal´ yzu, neboli luˇstˇen´ı zaˇsifrovan´ ych zpráv. ˇ Sifrov´ an´ı je d˚ uleˇzit´ ym prvkem zabezpeˇcuj´ıc´ım data. Je pouˇzito vˇsude tam, kde je poˇzadováno nevyzrazen´ı tajné informace. Pouˇz´ıvá se proto pro zabezpeˇcen´ı pˇrenosu dat nebo archivaci dat. C´ılem této diplomové práce je návrh systému pro autentizaci a autorizaci uˇzivatel˚ u. Uˇzivatel se bude autentizovat a autorizovat v˚ uˇci vzdálenému serveru. A proto bude potˇreba pˇrenáˇset d˚ uvˇerná data pˇres poˇc´ıtaˇcovou s´ıt’. Kryptografické metody budou pouˇzity právˇe k u ´ˇcelu utajen´ı pˇrenáˇsen´ ych d˚ uvˇern´ ych dat.

2.1

Symetrick´ aˇ sifra

Symetrické ˇsifrován´ı je zaloˇzeno na principu jednoho kl´ıˇce, kter´ ym lze zprávu jak zaˇsifrovat, tak i deˇsifrovat. Podstatnou v´ yhodou symetrick´ ych ˇsifer je jejich n´ızká v´ ypoˇcetn´ı nároˇcnost. Algoritmy pro ˇsifrován´ı s veˇrejn´ ym kl´ıˇcem (asymetrické algoritmy) mohou b´ yt i stotis´ıckrát pomalejˇs´ı. Na druhou stranu velkou nev´ yhodou je nutnost sd´ılen´ı tajného kl´ıˇce, proto se odesilatel a pˇr´ıjemce tajné zprávy mus´ı pˇredem domluvit na tajném kl´ıˇci.

Obrázek 2.1: symetrick´ y algoritmus

4

2.2

Asymetrick´ aˇ sifra

Asymetrická kryptografie (kryptografie s veˇrejn´ ym kl´ıˇcem) je skupina kryptografick´ ych metod, ve kter´ ych se pro ˇsifrován´ı a deˇsifrován´ı pouˇz´ıvaj´ı odliˇsné kl´ıˇce. ˇ Sifrovac´ ı kl´ıˇc pro asymetrickou kryptografii sestává z dvou ˇcást´ı: jedna ˇcást se pouˇz´ıv´ a pro ˇsifrován´ı zpráv (a pˇr´ıjemce zprávy ani tuto ˇcást nemus´ı znát), druhá pro deˇsifrov´ an´ı (a odesilatel ˇsifrovan´ ych zpráv ji zpravidla nezná). Je vidˇet, ˇze ten, kdo ˇsifruje, nemus´ı s deˇsifruj´ıc´ım pˇr´ıjemcem zprávy sd´ılet ˇzádné tajemstv´ı, ˇc´ımˇz eliminuj´ı potˇrebu v´ ymˇeny kl´ıˇc˚ u; tato vlastnost je základn´ı v´ yhodou asymetrické kryptografie. Nejbˇeˇznˇejˇs´ı verz´ı asymetrické kryptografie je vyuˇz´ıván´ı tzv. veˇrejného a soukromého ˇ kl´ıˇce. Sifrovac´ ı kl´ıˇc je veˇrejn´ y, majitel kl´ıˇce ho volnˇe uveˇrejn´ı, a kdokoli j´ım m˚ uˇze ˇsifrovat jemu urˇcené zprávy; deˇsifrovac´ı kl´ıˇc je soukrom´ y, majitel jej drˇz´ı v tajnosti a pomoc´ı nˇej m˚ uˇze tyto zprávy deˇsifrovat. Je zˇrejmé, ˇze ˇsifrovac´ı kl´ıˇc ecryptionKey a deˇsifrovac´ı kl´ıˇc decryptionKey spolu mus´ı b´ yt matematicky svázány, avˇsak nezbytnou podm´ınkou pro uˇziteˇcnost ˇsifry je praktick´ a nemoˇznost ze znalosti ˇsifrovac´ıho kl´ıˇce spoˇc´ıtat deˇsifrovac´ı. Matematicky tedy asymetrická kryptografie postupuje následuj´ıc´ım zp˚ usobem: ˇ Sifrov´ an´ı crypted = f(message, ecryptionKey) Deˇsifrován´ı message = g(crypted, decryptionKey) V principu se mohou ˇsifrovac´ı a deˇsifrovac´ı funkce liˇsit, zpravidla jsou vˇsak matematicky pˇrinejmenˇs´ım velmi podobné.

Obrázek 2.2: asymetrick´ y algoritmus

5

Kapitola 3

Autentizace a autorizace Autentizace a autorizace se pouˇz´ıvá pro zajiˇstˇen´ı pˇr´ıstupu k systému nebo sluˇzbˇe jen tˇem uˇzivatel˚ um, kteˇr´ı jsou k tomu oprávnˇeni. Tyto pojmy u ´zce souvis´ı s tématem diplomové práce, nebot’ jedn´ım z c´ıl˚ u práce je návrh autentizaˇcn´ıho a autorizaˇcn´ıho mechanismu.

3.1

Autentizace

Autentizace znamená potvrzen´ı, ˇze uˇzivatel poˇzaduj´ıc´ı sluˇzby je platn´ ym uˇzivatelem poskytovan´ ych s´ıt’ov´ ych sluˇzeb. Autentizace je dosaˇzena pomoc´ı pˇredstaven´ı identity a jistého povˇeˇren´ı nebo tajemstv´ı. Autentizace m˚ uˇze b´ yt jednosmˇerná nebo obousmˇerná. Jednosmˇerná oznaˇcuje autentizaci uˇzivatele v˚ uˇci serveru. Zde m˚ uˇze doj´ıt k podvrˇzen´ı identity serveru, proto je vhodné vyuˇz´ıt autentizaci obousmˇernou. Ta umoˇzn ˇuje ovˇeˇren´ı identity jak uˇzivatele tak i serveru poskytuj´ıc´ıho sluˇzbu. V ideáln´ım pˇr´ıpadˇe je tedy zamezeno podvrˇzen´ı identity od obou koncov´ ych ˇclen˚ u.

3.2

Zp˚ usoby autentizace

Uˇ zivatelsk´ e jm´ eno a heslo Znalost uˇzivatelského jména a hesla je nejznámˇejˇs´ım a nejbˇeˇznˇejˇs´ım zp˚ usobem autentizace uˇzivatele. K potvrzen´ı identity staˇc´ı znát uˇzivatelské jméno a heslo. V´ yhodou je snadn´ a implementace tohoto autentizaˇcn´ıho procesu a jeho nenároˇcnost na samotného uˇzivatele. Autentizaˇcn´ı u ´daje se mˇen´ı jen zˇr´ıdka a proto je moˇzno je z´ıskat velmi jednoduˇse. Ve chv´ıli, kdy se nám podaˇr´ı tyto u ´daje z´ıskat, at’ uˇz odposlechem nebo jin´ ym zp˚ usobem, z´ıskáme pln´ y pˇr´ıstup k uˇzivatelovu u ´ˇctu. Spolehlivost autentizace je nav´ıc velmi závislá na zvoleném hesle.

Jednor´ azov´ e heslo Jednou z nejjistˇejˇs´ıch obran proti odhalen´ı hesla nebo jeho odchycen´ı pˇri komunikaci je pouˇz´ıván´ı jednorázov´ ych hesel. Vˇetˇsina implementac´ı poskytuj´ıc´ıch autentizaci jednorázov´ ym heslem vyˇzaduje kromˇe zvláˇstn´ı konfigurace poˇc´ıtaˇcového systému i speciáln´ı zaˇr´ızen´ı v podobˇe kalkulátoru velikosti bˇeˇzné kreditn´ı karty, kter´ ym si uˇzivatel pokaˇzdé vygeneruje

6

nové heslo. Toto heslo je platné pouze po omezen´ y ˇcasov´ yu ´sek (maximálnˇe nˇekolik minut) a cel´ y pˇr´ıstroj je chránˇen proti zneuˇzit´ı ciz´ı osobou dalˇs´ım heslem nebo ˇc´ıseln´ ym kódem. Jednorázové heslo se vˇetˇsinou generuje v závislosti na aktuáln´ım ˇcase a/nebo sériovém ˇc´ısle zaˇr´ızen´ı. Posloupnost generovan´ ych hesel nelze odhadnout, dvoj´ı pouˇzit´ı stejného hesla nen´ı moˇzné.

Certifik´ at Dalˇs´ı moˇznost´ı je pouˇzit´ı certifikátu, kter´ y byl vystaven na stranˇe serveru. Certifikát pak pouˇz´ıvá sluˇzba pro ovˇeˇren´ı totoˇznosti jeho drˇzitele. Po technické stránce se jedná o textov´ y dokument, kter´ y m˚ uˇze b´ yt uloˇzen na libovolném médiu. Velmi ˇcasto se m˚ uˇzeme setkat s certifikáty uloˇzen´ ymi na pevném disku, odkud je lze zkop´ırovat. Jakmile dojde k odcizen´ı certifikátu a pˇr´ısluˇsn´ ych privátn´ıch kl´ıˇc˚ u, je moˇzno opˇet z´ıskat pln´ y pˇr´ıstup k u ´ˇctu p˚ uvodn´ıho majitele. Pouˇz´ıvá se proto um´ıstˇen´ı certifikátu na ˇcipovou kartu, jej´ıˇz ˇcteˇcku pak mus´ı m´ıt uˇzivatel pˇripojenu ke svému poˇc´ıtaˇci, nebo uloˇzen´ı certifikátu na serveru certifikaˇcn´ı autority (CA).

Autentizaˇ cn´ı kalkul´ ator Autentizaˇcn´ı kalkulátor je elektronické zaˇr´ızen´ı, které dokáˇze generovat jednorázová hesla pro pˇr´ıstup k u ´ˇctu uˇzivatele. Tato zaˇr´ızen´ı b´ yvaj´ı synchronizována se systémy na stranˇe serveru tak, aby obˇe strany generovaly stejné kl´ıˇce. Ty pak uˇzivatel opisuje do aplikace a ovˇeˇruje tak svou totoˇznost jednoduˇse t´ım, ˇze dokáˇze, ˇze je majitelem pˇr´ısluˇsného kalkulátoru. Jedná se o jednu z nejbezpeˇcnˇejˇs´ıch metod autorizace uˇzivatele.

3.3

Autorizace

Autorizace znamená udˇelen´ı specifického typu sluˇzby (vˇcetnˇe odm´ıtnut´ı sluˇzby) uˇzivateli na základˇe jeho autentizace, sluˇzeb, které poˇzaduje a aktuáln´ıho stavu systému. Autorizace m˚ uˇze b´ yt zaloˇzena na omezen´ıch, napˇr´ıklad omezen´ı na urˇcité hodiny v rámci dne, nebo omezen´ı na fyzickou polohu, nebo omezen´ı v´ıcenásobného pˇrihláˇsen´ı jednoho uˇzivatele. Autorizace urˇcuje povahu sluˇzby, která je poskytnuta uˇzivateli. Typy sluˇzeb jsou napˇr´ıklad: filtrován´ı IP adres, pˇridˇelen´ı adresy, pˇridˇelen´ı cesty, QoS, ˇr´ızen´ı ˇs´ıˇrky pásma/ˇr´ızen´ı toku, tunelován´ı do konkrétn´ıho koncového bodu. Ukázka autorizaˇcn´ıho záznamu: iptables -A INPUT -s 192.168.0.2 -p tcp --dport 443 -j REJECT Popis: vˇsechny dotazy na TCP portu 443 pˇricházej´ıc´ı z adresy 192.168.0.2 odm´ıtni

7

Kapitola 4

AAA sch´ ema V oblasti poˇc´ıtaˇcové bezpeˇcnosti AAA znamená authentication, authorisation and accounting protocol, tj. ˇcesky autentizaˇcn´ı, autorizaˇcn´ı a u ´ˇctovac´ı protokol. Autentizace a autorizace ´ ctován´ı znamená sledován´ı vyuˇz´ıván´ı s´ıt’ov´ byla vysvˇetlena v u ´vodu. Uˇ ych sluˇzeb uˇzivateli. Tyto informace mohou b´ yt pouˇzity pro správu, plánován´ı, u ´ˇctován´ı, nebo dalˇs´ı u ´ˇcely. ´ ctován´ı v reálném ˇcase je doruˇceno souˇcasnˇe s vyuˇz´ıván´ım zdroj˚ Uˇ u. Bˇeˇznˇe se sb´ıraj´ı informace o identitˇe uˇzivatele, povaze dodan´ ych sluˇzeb a ˇcasy poˇcátk˚ u a konc˚ u dodan´ ych sluˇzeb. Pokud bychom chtˇeli kontrolovat autentizaci, autorizaci a u ´ˇctován´ı pro celou lokáln´ı ’ s´ıt , bylo by potˇreba tyto tˇri sluˇzby um´ıstit do jednoho uzlu, kter´ y bude dané ˇzádané u ´daje ovˇeˇrovat a zaznamenávat. K tomuto u ´ˇcelu se pouˇz´ıvaj´ı ovˇeˇrovac´ı servery, zapojené do s´ıtˇe a ukryté nˇekde hloubˇeji (viz obrázek 4.1). V diplomové práci jsem navrhoval autentizaˇcn´ı a autorizaˇcn´ı mechanismus, kter´ y vych´ az´ı z AAA schématu. Informace uvedené v této kapitole slouˇzily jako inspirace pˇri návrhu tohoto mechanismu. Postup ovˇ eˇ rov´ an´ı (obr´ azek 4.1): ˇ adá pˇr´ıstupov´ • Klient ˇc. 2 je oprávnˇen´ y uˇzivatel. Z´ y bod (AP) o pˇr´ıstup k s´ıti. AP se zeptá ovˇeˇrovac´ıho serveru, zda má klient ˇc. 2 povolen pˇr´ıstup k s´ıti. Ovˇeˇrovac´ı server odpov´ıdá, ˇze uˇzivatel ˇc. 2 je oprávnˇen´ ym uˇzivatelem. Pˇristupov´ y bod povol´ı uˇzivateli ˇc. 2 vstup do s´ıtˇe. ˇ adá pˇr´ıstupov´ • Klient ˇc. 3 je neoprávnˇen´ y uˇzivatel. Z´ y bod (AP) o pˇr´ıstup k s´ıti. AP se zeptá ovˇeˇrovac´ıho serveru, zda má klient ˇc. 3 povolen pˇr´ıstup k s´ıti. Ovˇeˇrovac´ı server odpov´ıdá, ˇze uˇzivatel ˇc. 3 nen´ı oprávnˇen´ ym uˇzivatelem. Pˇristupov´ y bod zak´ aˇze uˇzivateli ˇc. 3 vstup do s´ıtˇe. Principu protokolu AAA vyuˇz´ıvaj´ı mnohé dalˇs´ı protokoly. Jsou pouˇzity napˇr´ıklad v lokán´ıch ethernetov´ ych s´ıt´ıch, mobiln´ıch s´ıt´ıch a bezdrátov´ ych s´ıt´ıch.

8

Obrázek 4.1: autentizace pomoc´ı ovˇeˇrovac´ıho serveru

4.1

Radius

RADIUS (Remote Authentication Dial In User Service, ˇcesky Uˇzivatelská vytáˇcená sluˇzba pro vzdálenou autentizaci) je AAA protokol pouˇz´ıvan´ y pro pˇr´ıstup k s´ıti nebo pro IP mobilitu. Pˇri pˇripojen´ı k poskytovateli Internetu pomoc´ı vytáˇceného pˇripojen´ı, DSL, nebo WiFi je u nˇekter´ ych poskytovatel˚ u vyˇzadováno pˇrihlaˇsovac´ı uˇzivatelské jméno a heslo. Tato informace je poslána do takzvaného Network Access Server (NAS) zaˇr´ızen´ı pˇres Pointto-Point Protocol (PPP [15]). Poté je pˇredána RADIUS serveru pˇres RADIUS protokol. RADIUS server ovˇeˇr´ı pravost informace. Pokud je uˇzivatelské jméno a heslo pˇrijato, server autorizuje pˇr´ıstup k poskytovateli internetu a vybere IP adresu a dalˇs´ı parametry spojen´ı. RADIUS server bude také upozornˇen na spuˇstˇen´ı nebo ukonˇcen´ı sezen´ı, takˇze uˇzivatel m˚ uˇze platit pˇresnˇe podle tˇechto RADIUS informac´ı nebo mohou b´ yt tyto pouˇzity pro statistické u ´ˇcely. RADIUS byl p˚ uvodnˇe vyvinut spoleˇcnost´ı Livingston Enterprises pro jejich PortMaster série Network Access Servers a pozdˇeji (1997) zveˇrejnˇeny jako RFC 2058 [13] a RFC 2059 [11] (souˇcasné verze jsou RFC 2865 [14] a RFC 2866 [12]). V souˇcasné dobˇe existuje nˇekolik komerˇcn´ıch a open-source RADIUS server˚ u. Vlastnosti se liˇs´ı, ale vˇetˇsina umoˇzn ˇuje dohledávat uˇzivatele v textov´ ych souborech, LDAP serverech, r˚ uzn´ ych databáz´ıch a podobnˇe. RADIUS proxy servery jsou pouˇz´ıvány pro centráln´ı správu a mohou pˇrepisovat RADIUS pakety za bˇehu.

9

Obrázek 4.2: Radius paket

• Kód – definuje typ RADIUS paketu Nejˇcastˇejˇs´ı typy zpráv v protokolu RADIUS: – Access-Request - klient protokolu RADIUS (pˇr´ıstupov´ y server) odes´ılá poˇzadavek na ovˇeˇren´ı uˇzivatele na RADIUS serveru. – Access-Accepted - RADIUS server sdˇeluje, ˇze uˇzivatel m˚ uˇze dostat povolen´ı ’ do s´ıtˇe. – Access-Reject - RADIUS server zam´ıtá pˇr´ıstup do s´ıt’ˇe. – Access-Challenge - RADIUS server odes´ılá poˇzadavek pˇr´ıstupovému serveru, aby klient zadal jednorázové heslo. • Identifikátor – ˇc´ıslo zprávy • Délka – délka paketu • Autentikátor – slouˇz´ı pro autentizaci (je zde uloˇzen MD5 hash uˇzivatelského hesla) • Atributy – zde se zas´ılaj´ı r˚ uzné informace jako uˇzivatelské jméno, heslo...

Autentizace obsahuje dva dialogy: 1. mezi uˇzivatelem a pˇr´ıstupov´ ym bodem a c´ılem je sestavit zprávu Access-Request 2. dialog protokolu RADIUS obsahuj´ıc´ı napˇr. zprávy Access-Request a Access-Accepted mezi pˇr´ı-stupov´ ym bodem a RADIUS serverem Pˇr´ıstupov´ y server si také mus´ı b´ yt jist´ y, ˇze jedná s korektn´ım RADIUS serverem. M˚ uˇze nastat pˇr´ıpad, ˇze podvrˇzen´ y RADIUS server by povolil pˇr´ıstup do s´ıtˇe neoprávnˇenému uˇzivateli. Proto RADIUS server do své odpovˇedi vkládá ˇretˇezec, kter´ ym svou odpovˇed’ autorizuje. Autorizace prob´ıhá na základˇe sd´ıleného tajemstv´ı, které zná pouze RADIUS server a pˇr´ıstupov´ y server. RADIUS je jako autentizaˇcn´ı protokol bˇeˇznˇe pouˇz´ıván v IEEE 802.1x bezpeˇcnostn´ım standardu [6] (ˇcasto pouˇz´ıván v bezdrátov´ ych s´ıt´ıch). I kdyˇz nebyl RADIUS p˚ uvodnˇe vytvoˇren pro autentizaˇcn´ı metody v bezdrátov´ ych s´ıt´ıch, vylepˇsuje zabezpeˇcen´ı ve spojen´ı s ostatn´ımi bezpeˇcnostn´ımi metodami jako EAP-PEAP. RADIUS je rozˇsiˇriteln´ y a vˇetˇsina v´ yrobc˚ u zaˇr´ızen´ı a software pouˇz´ıvaj´ı vlastn´ı RADIUS dialekty. V roce 2003 byl vytvoˇren návrh protokolu DIAMETER, kter´ y je plánován jako náhrada RADIUS protokolu.

10

4.2

Diameter

Hlavn´ı koncept tvoˇr´ı základn´ı protokol (RFC 3588 [5]), kter´ y m˚ uˇze b´ yt rozˇs´ıˇren pro poskytován´ı AAA sluˇzeb nov´ ym pˇr´ıstupov´ ym technologi´ım. Pˇredch˚ udcem protokolu DIAMETER je protokol RADIUS (anglické diameter je ˇcesky pr˚ umˇer, coˇz je dvakrát v´ıce neˇz polomˇer, anglicky radius). Diameter nen´ı pˇr´ımo zpˇetnˇe kompatibiln´ı, ale poskytuje rozˇs´ıˇrenou cestu pro RADIUS. Hlavn´ı rozd´ıly protokolu DIAMETER oproti protokolu RADIUS jsou: • pouˇz´ıvá spolehliv´ y transportn´ı protokol (TCP nebo SCTP, nepouˇz´ıvá nespolehliv´ y UDP) • podporuje pˇrenos RADIUS • má vˇetˇs´ı adresn´ı prostor pro dvojice hodnot atribut˚ u (anglicky Attribute Value Pairs, AVPs) a ˇsirˇs´ı identifikátory (32bitové m´ısto 8bitov´ ych) • jde o klient-server protokol, s v´ yjimkou podpory nˇekter´ ych zpráv inicializovan´ ych serverem • lze pouˇz´ıt stavov´ y i bezstavov´ y model • podporuje dynamické objevován´ı uzl˚ u (pouˇz´ıvá DNS, SRV a NAPTR) • obsahuje schopnost vyjednáván´ı • podporuje dohody na aplikaˇcn´ı vrstvˇe, definuje metody odolávaj´ıc´ı chybám a stavové stroje (RFC 3539 [2]) • oznamuje chyby • má lepˇs´ı podporu roamingu • je snadnˇeji rozˇsiˇriteln´ y; lze definovat nové pˇr´ıkazy a atributy • je zarovnán na 32bitové hranice • má základn´ı podporu uˇzivatelsk´ ych sezen´ı a u ´ˇctován´ı

Z´ akladn´ı protokol Diametru Základn´ı protokol Diameteru (Diameter Base Protocol) je definován v RFC 3588 [5]. Urˇcuje minimáln´ı poˇzadavky AAA protokolu. Aplikace Diameteru mohou rozˇs´ıˇrit základn´ı protokol pˇridán´ım nov´ ych pˇr´ıkaz˚ u nebo atribut˚ u. Aplikace zde nen´ı program, n´ ybrˇz protokol zaloˇzen´ y na Diameteru.

4.3

EAP

EAP (Extensible Authentication Protocol - RFC 2284 [3]) byl p˚ uvodnˇe urˇcen pouze pro ’ protokol PPP (Point-to-Point Protocol). Zajiˇst uje pro nˇej rámec (transportn´ı mechanismus) pro vˇsechny druhy ovˇeˇrovac´ıch metod, nicménˇe nen´ı jeho ned´ılnou souˇcást´ı. Definice EAP 11

mimo PPP, do samo-statného protokolu, umoˇznilo jeho pouˇzit´ı i v jin´ ych prostˇred´ıch. Napˇr. modifikace EAP definovaná pod specifikac´ı IEEE 802.1x je v podstatˇe rozˇs´ıˇren´ı EAP pro s´ıtˇe typu 802. Protokol EAP sám o sobˇe nezajist´ı bezpeˇcn´ y ovˇeˇrovac´ı mechanismus - ten se vyjedná aˇz protokolem EAP. Protokol EAP umoˇzn ˇuje pouˇz´ıt libovoln´ y ovˇeˇrovac´ı mechanizmus, kter´ y staˇc´ı implementovat na obou stranách spojen´ı. Toto umoˇzn ˇuje pomˇernˇe snadno vytváˇret nové modifikace protokolu. Protokol se v principu nemˇen´ı, jen ovˇeˇrovac´ı mechanismus mus´ı b´ yt znám´ y na obou stranách spojen´ı. Pokud se pouˇzije protokol EAP, pak se fáze autentizace skládá: • dohoda na ovˇeˇrovac´ım mechanizmu • vlastn´ı autentizace Navazov´ an´ı spojen´ı 1. Pˇr´ıstupov´ y bod, kter´ y ovˇeˇruje totoˇznost klienta, zaˇsle zprávu EAP-Request. T´ım ˇzád´ a klienta o prokázán´ı totoˇznosti. 2. Pokud klient souhlas´ı - odpov´ıdá zprávou EAP-Response. 3. Pˇr´ıstupov´ y bod zaˇsle zprávu EAP-Request v´ yzvu (Challenge) 4. Klient spoj´ı sd´ılené tajemstv´ı (heslo) s v´ yzvou a minimálnˇe aplikuje jednocestnou funkci MD5 a v´ ysledek vloˇz´ı do odpovˇedi EAP-Response. 5. Pˇr´ıstupov´ y bod ovˇeˇr´ı totoˇznost klienta a odpov´ı EAP-Succes/EAP-Failure (potvrd´ı/zam´ıtne). Nejˇ castˇ ejˇ s´ı typy ovˇ eˇ rovac´ıch mechanism˚ u: • EAP-MD5 (RFC 1994, RFC 2284) Pro ovˇeˇrován´ı je pouˇz´ıváno uˇzivatelské jméno a heslo. Tyto u ´daje jsou pro zajiˇstˇen´ı pravosti hashovány pomoc´ı MD5. Jedná se o p˚ uvodn´ı specifikaci s jednocestn´ ym ovˇeˇrován´ım. Tento zp˚ usob ovˇeˇrován´ı nen´ı vhodn´ y u bezdrátov´ ych s´ıt´ı - hroz´ı riziko odposlouchán´ı. • EAP-TLS (RFC 2716) Transport Level Security Pro ovˇeˇrován´ı pouˇzito PKI (Public Key Infrastructure) a SSL (Secure Sockets Layer), mechanismus ovˇeˇrován´ı je zaloˇzen na pouˇzit´ı ovˇeˇren´ı serveru na základˇe certifikátu serveru a ovˇeˇren´ı uˇzivatele na základˇe certifikátu uˇziva-tele. Kl´ıˇce jsou generovány dynamicky. Zprávy jsou chránˇené pˇred naslouchán´ım TLS (Transport Layer Security) tunelem. Nev´ yhoda - udrˇzován´ı PKI certifikát˚ u pro klienta a server. Vhodné pro WLAN - TSL tunel chrán´ı pˇrenos pˇred odposlechem. • EAP-TTLS (Tunneled TLS); rozˇs´ıˇren´ı modifikace EAP-TLS, ale bez pouˇzit´ı certifikát˚ u. Klient se prokazuje jménem a heslem. Vhodné tam, kde jsou poˇzadavky na bezpeˇcnost bez pouˇzit´ı spoleˇcn´ ych certifikát˚ u. • EAP-PEAP (Protected EAP); podobn´ y TTLS, zajiˇst’uje TLS k vytvoˇren´ı tunelu pro druh´ y ovˇeˇrovac´ı algoritmus, ten je typu EAP. EAP-PEAP dovoluje dalˇs´ım EAP ovˇeˇrovac´ım protokol˚ um pouˇz´ıvat zabezpeˇcuj´ıc´ı pˇrenos TLS tunelem. 12

• EAP-LEAP (Lightweight Extensible Authentication Protocol); Navrˇzeno firmou Cisco. Podporuje vzájemné ovˇeˇren´ı klienta a s´ıtˇe. Podobné jako EAP-TLS, ale m´ısto certifikát˚ u pouˇz´ıvá jméno a heslo. • EAP-OTP One-Time Password Ovˇeˇrován´ı je zajiˇst’ováno pomoc´ı systém˚ u typu RSA SecureID, CRYPTOCard Token,... • EAP-GTC (Generic Token Card) Obdoba EAP-OTP. • EAP-AKA - Authentication and Key Agreement Pouˇzit´ı v UMTS s´ıt´ıch. • EAP-SKE - Shared Key Exchange • EAP-GPRS - modifikace pro GPRS

4.4

802.1x

Rámec 802.1x nepatˇr´ı pˇr´ımo do rodiny protokol˚ u AAA, ale lze na nˇem demonstrovat principy AAA protokolu. IEEE 802.1x je obecn´ y bezpeˇcnostn´ı rámec pro vˇsechny typy LAN, zahrnuj´ıc´ı autentizaci uˇzivatel˚ u, integritu zpráv (ˇsifrován´ım) a distribuci kl´ıˇc˚ u. Protokol 802.1x má za c´ıl blokovat pˇr´ıstup k segmentu lokáln´ı s´ıtˇe pro neoprávnˇené uˇzivatele. Je zaloˇzen´ y na protokolu Extensible Authentication Protocol (EAP, RFC 2284 [3]). Jedná se o mechanizmus pˇrenosu EAP paket˚ u prostˇrednictv´ım spojové vrstvy LAN (typu 802) - zprávy EAP se zapouzdˇruj´ı do rámc˚ u 802.1x. Jednou z kl´ıˇcov´ ych vlastnost´ı 802.1x je to, ˇze pˇr´ıstupov´ y bod – NAS (network access server) m˚ uˇze b´ yt v podstatˇe jednoduch´ y. Veˇskerá inteligence je v klientovi a ovˇeˇrovac´ım serveru. To je pro pˇr´ıstupové body ideáln´ı, protoˇze jsou typicky pomˇernˇe jednoduché s malou pamˇet´ı a v´ ykonem procesoru. Ovˇeˇrován´ı provád´ı pˇr´ıstupov´ y bod pro klienty na základˇe jejich v´ yzvy pomoc´ı seznamu nebo extern´ıho autentizaˇcn´ıho systému (serveru Kerberos nebo RADIUS). Pouze ovˇeˇren´ y uˇzivatel má moˇznost pˇr´ıstupu do s´ıtˇe. Postup autentizace podle 802.1x - obrázek 4.3 (je uvaˇzován jen jednoduch´ y ovˇeˇrovac´ı algoritmus jednocestnou funkc´ı MD5) Postup ovˇ eˇ rov´ an´ı: 1. 1. Klient pos´ılá poˇzadavek pˇr´ıstupovému serveru (tj. switch nebo bezdrátov´ y pˇr´ıstupov´ y bod), ˇze se chce pˇrihlásit do s´ıtˇe (EAPOL-Start). 2. Pˇr´ıstupov´ y server pos´ılá klientovi poˇzadavek na ovˇeˇren´ı totoˇznosti (EAP-Request/ Identity). Pokud pˇr´ıstupov´ y server (Network Acces Server - NAS) detekuje pˇr´ıtomnost klienta, tak zaˇsle poˇzadavek na ovˇeˇren´ı bez ˇcekán´ı na kontakt od klienta. 3. Klient pos´ılá pˇr´ıstupovému serveru informaci o své totoˇznosti (EAP-Response/Identity). Pˇr´ıstupov´ y server ji pˇrebal´ı z EAP do RADIUS protokolu a posune ji na RADIUS server.

13

Obrázek 4.3: 802.1x autentizace

4. RADIUS server pos´ılá zpˇet na pˇr´ıstupov´ y server v´ yzvu pro ovˇeˇren´ı (challenge). Pˇr´ıstupov´ y server pˇrebal´ı zprávu z formátu RADIUS do EAPOL a poˇsle ji klientovi . Rozd´ılné ovˇeˇrovac´ı metody maj´ı r˚ uzné mnoˇzstv´ı paket˚ u v této ˇcásti procesu . EAP podporuje jak jednoduché ovˇeˇren´ı klienta tak i silné vzájemné ovˇeˇrován´ı. 5. Klient na v´ yzvu odpov´ıdá napˇr. tak, ˇze k v´ yzvˇe pˇridá své heslo a tento ˇretˇezec zaˇsifruje hash funkc´ı. Zaˇsifrovanou zprávu pos´ılá jako odpovˇed’ na pˇr´ıstupov´ y server. Ten ji pˇrepoˇsle dál na RADIUS server. 6. RADIUS server zkontroluje u ´daje a odpov´ı zprávou o u ´spˇeˇsnosti/ne´ uspˇeˇsnosti, kter´ a je pˇreposlána klientovi. Pˇr´ıstupov´ y server umoˇzn´ı (neumoˇzn´ı) pˇr´ıstup do s´ıtˇe - s moˇznost´ı restrikc´ı na základˇe atribut˚ u od RADIUS serveru. Napˇr´ıklad pˇriˇrad´ı klienta do konkrétn´ı VLAN nebo nastav´ı filtrovac´ı pravidla.

14

Architektura 802.1x Jak jiˇz bylo ˇreˇceno EAP protokol zajiˇst’uje pouze transportn´ı mechanismus pro ovˇeˇrov´ an´ı - t´ım je umoˇznˇeno vytváˇret nové modifikace protokolu - obrázek 4.4.

Obrázek 4.4: architektura

• vrstva ovˇeˇrovac´ı metody - ˇreˇs´ı konkrétn´ı metodu ovˇeˇren´ı uˇzivatele (viz. protokol EAP) • 801.1x vrstva - zajiˇstˇen´ı pravidel pro komunikaci komponentami systému (supplicant, authenticator a authentication server) • Linková vrstva - uzp˚ usoben´ı konkrétn´ı LAN technologii (definice specifick´ ych rámc˚ u)

4.5

Shrnut´ı

V této kapitole byly rozebrány principy AAA protokolu a byly zde zm´ınˇeny aplikace pouˇz´ıvaj´ıc´ı pˇr´ıstup AAA schématu. C´ılem diplomové práce byl návrh autentizaˇcn´ıho mechanismu pomoc´ı d˚ uvˇeryhodného serveru. Tento server mˇel v podstatˇe splˇ novat základn´ı poˇzadavky AAA schématu. Proto jsem pro roli d˚ uvˇeryhodného serveru vybral server Radius.

15

Kapitola 5

Autentizace pomoc´ı syst´ emu Kerberos Kerberos je jak protokol tak i systém zajiˇst’uj´ıc´ı autentizaci a autorizaci uˇzivatel˚ u. Je definován standardem IETF RFC 1510 [9] a tvoˇr´ı základn´ı autenizaˇcn´ı prvek v ˇradˇe komerˇcn´ıch i open-source systém˚ u. Kerberos je navrˇzen tak, aby zajiˇst’oval silné zabezpeˇcen´ı souˇcasnˇe s jednoduch´ ym uˇzivatelsk´ ym rozhran´ım. Zp˚ usob autentizace je zaloˇzen na pouˇzit´ı tzv. l´ıstk˚ u vydávan´ ych centráln´ım autentizaˇcn´ım serverem, kter´ y spravuje databázi vˇsech uˇzivatel˚ u. L´ıstky jsou analogické napˇr. certifikát˚ um veˇrejn´ ych kl´ıˇc˚ u, ale narozd´ıl od nich jsou kerberovské l´ıstky a vˇsechny kerberovské protokoly zaloˇzeny v´ yhradnˇe na pouˇzit´ı symetrické kryptografie, tj. hesla sd´ıleného mezi uˇzivatelem a centráln´ım autentizaˇcn´ım serverem. Kerberovské l´ıstky maj´ı také kratˇs´ı dobu platnosti (zpravidla deset hodin) a vˇzdy obsahuj´ı informaci, pro kterou konkrétn´ı koncovou sluˇzbu jsou urˇceny. Systém Kerberos ve vztahu k diplomové práci slouˇzil jako inspirace. Byly na nˇem zkoumány autentizaˇcn´ı postupy a principy. Pˇri implementaci byl pouˇzit pro anal´ yzu zdrojov´ ych kód˚ u aplikac´ı pouˇz´ıvaj´ıc´ıch autentizaci pomoc´ı d˚ uvˇeryhodné tˇret´ı strany.

Historie Prvn´ı verze byly vyvinuty v rámci projektu Athena v letech 1983-1991 v laboratoˇr´ıch MIT (Massachusetts Institute of Technology) a prvn´ı veˇrejnou verz´ı byla verze v4. Po zhruba ˇsestiletém v´ yvoji a upravován´ı na základˇe zkuˇsenost´ı uˇzivatel˚ u vznikla verze v5, která se v souˇcasnosti pouˇz´ıvá.

5.1

Protokol Kerberos

Hlavn´ı ˇcást´ı systému Kerberos je KDC (Key Distribution Center), které je d˚ uvˇeryhodnou tˇret´ı stranou umoˇzn ˇuj´ıc´ı bezpeˇcnou autentizaci a autorizaci. KDC bezpeˇcnˇe uchovává data o uˇzivatel´ıch a sluˇzbách v s´ıti.

16

KDC se dˇ el´ı na dva subsyst´ emy: • AS - autentizaˇcn´ı server, zajiˇst’uje autentizaci a autorizaci uˇzivatel˚ u a sluˇzeb • TGS - Ticket Grantig Server, zajiˇst’uje pˇridˇelován´ı oprávnˇen´ı - l´ıstk˚ u - k pouˇzit´ı zdroje (sluˇzby) Dále v systému vystupuj´ı klientské aplikace a servery, na nichˇz bˇeˇz´ı sluˇzby. Pˇri pˇr´ıstupu ke sluˇzbˇe je potˇreba ovˇeˇrit autentizaˇcn´ı u ´daje klienta serverem AS, kter´ y mu po u ´spˇeˇsné autentizaci vydá l´ıstek umoˇzn ˇuj´ıc´ı poˇzádat TGS o udˇelen´ı pˇr´ıstupu ke sluˇzbˇe. Jakmile ho klient obdrˇz´ı a prokáˇze se j´ım poˇzadované sluˇzbˇe, která ovˇeˇr´ı jeho platnost, m˚ uˇze b´ yt sluˇzba pouˇz´ıvána po dobu platnosti tohoto l´ıstku.

Proces autentizace a autorizace - viz. obr´ azek 5.1

Obrázek 5.1: autentizace a autorizace pomoc´ı protokolu kerberos

17

1. Klientsk´ y proces si vyˇzádá uˇzivatelské jméno, které poˇsle v nezaˇsifrované podobˇe AS (tzn. klient t´ımto ˇzádá o pˇridˇelen´ı TGT). AS má centráln´ı databázi uˇzivatel˚ ua sluˇzeb, kde se nalézá heslo uˇzivatele, které mus´ı b´ yt shodné s heslem znám´ ym na stranˇe klienta. 2. AS pˇrijme tuto ˇzádost (vˇetˇsinou tyto ˇzádosti ukládá kv˚ uli vˇetˇs´ı bezpeˇcnosti do cache), následnˇe podle uˇzivatelského jména vyhledá v centráln´ı databázi heslo uˇzivatele a z nˇej vygeneruje doˇcasn´ y kl´ıˇc - session-key. Vygeneruje dále tzv. TGT l´ıstek - Ticket Granting Ticket, kter´ y obsahuje: uˇzivatelské jméno, jméno TGS serveru (vydává oprávnˇen´ı pouˇz´ıt zdroj), s´ıt’ovou adresu klienta, session-key Tento TGT l´ıstek je poté zaˇsifrován pomoc´ı tajného kl´ıˇce, kter´ y je bezpeˇcnˇe sd´ılen pouze AS a TGS. 3. AS pos´ılá klientskému procesu tento TGT l´ıstek a spolu s n´ım mu pos´ılá také dvojici: session-key, n (nonce, náhodn´ y identifikátor ˇci timestamp kv˚ uli zv´ yˇsen´ı bezpeˇcnosti). Tato dvojice je zaˇsifrována klientsk´ ym (uˇzivatelsk´ ym) heslem uloˇzen´ ym v centráln´ı databázi AS. 4. Klientsk´ y proces pomoc´ı kl´ıˇce vygenerovaného ze svého uˇzivatelského hesla deˇsifruje tuto dvojici a z´ıská tak session-key a m˚ uˇze také zkontrolovat platnost n. Klient tedy nyn´ı vlastn´ı TGT a session-key, které budou dále pouˇzity v komunikaci s TGS. To, ˇze klient správnˇe deˇsifruje a z´ıská session-key, v podstatˇe znamená u ´spˇeˇsnou autentizaci v˚ uˇci AS. 5. Klientsk´ y proces ˇzádá nyn´ı o pouˇzit´ı sluˇzby t´ımto zp˚ usobem: vytvoˇr´ı si tzv. autentifikátor, kter´ y obsahuje (username,useraddress,timestamp), timestamp udává ˇcas vytvoˇren´ı autentifikátoru a jeho platnost. Tento autentifikátor je zaˇsifrován pomoc´ı session-key a odeslán TGS spolu s ˇzádost´ı o vyuˇzit´ı poˇzadované sluˇzby a TGT l´ıstkem. 6. TGS pˇrijme tyto u ´daje a pomoc´ı kl´ıˇce, kter´ y bezpeˇcnˇe sd´ıl´ı s AS deˇsifruje TGT l´ıstek, z nˇehoˇz z´ıská session-key. Pomoc´ı tohoto kl´ıˇce deˇsifruje autentifikátor a zkontroluje jestli souhlas´ı informace na TGT l´ıstku (username,useraddress) a v autentifikátoru. Dále zkontroluje jeho platnost - timestamp. 7. Po kladném ovˇeˇren´ı generuje nov´ y l´ıstek = povˇeˇren´ı pouˇz´ıt poˇzadovanou sluˇzbu bˇeˇz´ıc´ı na serveru S. TGS generuje nov´ y kl´ıˇc TGS-session-key, kter´ y bude pouˇzit v komunikaci klienta a serveru S. TGS vytvoˇr´ı l´ıstek (username,useraddress,timestamp), kter´ y zaˇsifruje pomoc´ı kl´ıˇce TGS-session-key a odeˇsle jej klientskému procesu spolu s nov´ ym TGS-session-key ˇsifrovan´ ym pomoc´ı session-key. 8. Klient tyto l´ıstky deˇsifruje pomoc´ı session-key a tak z´ıská TGS-session-key. Vlastn´ı tedy tento kl´ıˇc a souˇcasnˇe l´ıstek opravˇ nuj´ıc´ı pouˇz´ıt sluˇzbu serveru S. 9. Klientsk´ y proces vytváˇr´ı dalˇs´ı autentifikátor (username,useraddress,timestamp) ˇsifrovan´ y pomoc´ı TGS-session-key a pos´ılá jej na server S, kde bˇeˇz´ı poˇzadovaná sluˇzba. 10. Server S ovˇeˇr´ı u ´daje z autentifikátoru tak, ˇze deˇsifruje l´ıstek kl´ıˇcem, kter´ y sd´ıl´ı s TGS. Z´ıská z nˇej TGS-session-key, kter´ ym deˇsifruje autentifikátor a zkontroluje zda u ´daje souhlas´ı.

18

Shrnut´ı V této kapitole byl popsán protokol Kerberos a proces autentizace pomoc´ı systému Kerberos. V dalˇs´ı práci byl pouˇzit jako inspirace pro návrh autentizaˇcn´ıho mechanismu. Byl rovnˇeˇz vyuˇzit´ y pro anal´ yzu zdrojov´ ych kód˚ u aplikac´ı pouˇz´ıvaj´ıc´ıch autentizaci pomoc´ı d˚ uvˇeryhodné tˇret´ı strany.

19

Kapitola 6

Programov´ e n´ astroje pro autentizaci Kaˇzdá správnˇe navrhnutá aplikace by se mˇela skládat z hierarchicky strukturovan´ ych vrstev, které by mˇely zajiˇst’ovat specifickou funkˇcnost. Tyto vrstvy mezi sebou mus´ı komunikovat pˇres jasnˇe definované rozhran´ı. Tento pˇr´ıstup má ˇradu v´ yhod a mezi nejd˚ uleˇzitˇejˇs´ı patˇr´ı: • Odst´ınˇen´ı implementaˇcn´ıch detail˚ u niˇzˇs´ıch vrstev pˇred vrstvami vyˇsˇs´ımi – poskytuje vyˇsˇs´ım vrstvám abstraktn´ı pohled. • Niˇzˇs´ı vrstvy nejsou nijak svázány s vrstvami vyˇsˇs´ımi. O jejich existenci nevˇed´ı a nijak se na nˇe neodvolávaj´ı. • Zv´ yˇsen´ı pˇrehlednosti celé aplikace, která je pˇrehlednˇe rozdˇelena na jednotlivé funkˇcn´ı celky. • Jednoduché rozˇsiˇrován´ı funkˇcnosti aplikac´ı pˇridán´ım nové niˇzˇs´ı vrstvy. Ideáln´ı stav by byl, pokud by aplikace se stejn´ ym zamˇeˇren´ım (napˇr. s´ıt’ové aplikace s poˇzadavkem autentizace uˇzivatele) vyuˇz´ıvaly totoˇznou hierarchickou strukturu vrstev a jejich rozhran´ı. Liˇsily by se pouze ve funkˇcnosti jednotliv´ ych vrstev. Rozhran´ı by stále z˚ ustalo stejné. Toto by napˇr´ıklad umoˇznilo jednoduchou implementaci nového autentizaˇcn´ıho mechanismu do vˇsech existuj´ıc´ıch aplikac´ı. Avˇsak dodrˇzen´ı této podm´ınky je nereálné. Kaˇzdá rodina aplikac´ı pouˇz´ıvá svoje vlastn´ı definované vrstvy. Proto je nutné abych si vybral pro ˇreˇsen´ı diplomové práce právˇe jednu takovou skupinu aplikac´ı. Prozkoumal jej´ı vrstvy a rozhran´ı a modifikoval aplikace tak, aby byly schopny autentizovat uˇzivatele novˇe navrhnut´ ym mechanismem. Pro konkrétn´ı pˇr´ıpad studia autentizaˇcn´ıho rozhran´ı aplikac´ı jsem vybral komunikaci mezi poˇstovn´ım serverem imapd a emailov´ ym klientem pine.

6.1

Aplikace vybran´ e pro anal´ yzu

University of Washington (dále UW) a jej´ı fakulta Poˇc´ıtaˇc˚ u a Komunikac´ı se zab´ yvá jiˇz ’ dlouhou dobu v´ yzkumem a v´ yvojem s´ıt ov´ ych aplikac´ı. Jiˇz v roce 1989 lidé z univerzity vytvoˇrili známého emailového klienta pine. Dále vytvoˇrili i emailové servery POP2, POP3 a IMAP, které stále aktualizuj´ı a pˇrizp˚ usobuj´ı poˇzadavk˚ um modern´ı doby. 20

Jedn´ım z poˇzadavk˚ u byla i podpora nov´ ych autentizaˇcn´ıch protokol˚ u. Proto v dneˇsn´ı dobˇe vˇsechny aplikace vytvoˇrené washingtonskou univerzitou podporuj´ı ˇsirokou ˇskálu tˇechto protokol˚ u. Mezi nejd˚ uleˇ zitˇ ejˇ s´ı autentizaˇ cn´ı mechanismy patˇ r´ı: • ovˇeˇren´ı pomoc´ı unixového hesla • ovˇeˇren´ı pomoc´ı PAM modulu • ovˇeˇren´ı pomoc´ı systému Kerberos Z poslednˇe zm´ınˇeného systému Kerberos jsem vycházel pˇri anal´ yze autentizaˇcn´ıch mechanism˚ u implementovan´ ych v aplikac´ıch University of Washington. Jednalo se konkrétnˇe o bal´ıˇcek imap2006e (Pˇr´ıloha A), kter´ y obsahuje aplikace imapd, pop2d a pop3d a bal´ıˇcek pine4.64 (Pˇr´ıloha A), kter´ y obsauje emailového klienta pine. Tyto aplikace jsem rovnˇeˇz vyuˇzil pro implementaci novˇe navrhnutého autentizaˇcn´ıho mechanismu a demonstroval jsem na nich jeho funkˇcnost.

6.2

Instalace a konfigurace syst´ emu pro anal´ yzu

Jak jiˇz bylo zm´ınˇeno, aplikace UW z bal´ıˇcku imap2006e a pine4.64 obsahuj´ı stejné programové rozhran´ı pro autentizaˇcn´ı moduly. Proto nebylo nutné zkoumat vˇsechny aplikace pˇr´ıtomné v tomto bal´ıˇcku ale staˇcilo vybrat jen dvˇe pro komunikaci klient-server. Pro anal´ yzu a implementaci jsem vybral jako klientskou aplikaci emailového klienta pine a jako poˇstovn´ı server slouˇzil imapd.

Instalace C´ılem instalace bylo rozbˇehnut´ı poˇstovn´ıho IMAP serveru. Autentizace byla poˇzadována pˇres systém Kerberos. Proto jsem k instalaci vybral následuj´ıc´ı bal´ıˇcky: • postfix2.3.3-2- jako SMTP server • imap2006e- jehoˇz souˇcást´ı je IMAP server • krb51.6.1- systém Kerberos • pine emailov´ y klient Aby byl postup instalace jednoduˇse opakovateln´ y, provedl jsem instalaci systému na virtuáln´ım stroji aplikace VMware Player (Pˇr´ıloha A). Jako operaˇcn´ı systém poslouˇzila linuxová distribuce Fedora6 (Pˇr´ıloha A).

21

Seznam bal´ıˇck˚ u potˇrebn´ ych pro instalaci systému (detailn´ı postup instalace je popsán v pˇr´ıloze A): poˇ stovn´ı server postfix postfix-2.3.3-2 pcre-6.6-1.1 maildop-2.0.3 (verze 2.0.4 zp˚ usobovala problémy) Kerberos gcc-4.1.1-51 gcc-c++-4.1.1-51 openssl-0.9.8e (verze 0.9.8b zp˚ usobovala problémy) ncurses-5.6 byacc-1.9-29.2.2 flex-2.5.4a-41 libsepol-1.14 checkpolicy-1.34.1 libselinux-1.34.7 Linux-PAM-0.99.7.1 krb5-1.6.1 imap server xinetd-2.3.14-8 imap-2006e emailov´ y klient pine pine-4.64

Konfigurace Provedl jsem jednoduchou konfiguraci poˇstovn´ıho serveru a systému Kerberos (popis konfigurace je v pˇr´ıloze B). Jednotlivé systémy se konfigurovaly bud’ pomoc´ı konfiguraˇcn´ıch soubor˚ u, nebo jako v pˇr´ıpadˇe IMAP serveru zmˇenou parametr˚ u pˇri kompilaci aplikace.

6.3

Kerberizovan´ e aplikace

Chceme-li pouˇz´ıvat autentizaci pomoc´ı systému Kerberos, mus´ı b´ yt na klientském poˇc´ıtaˇci nainstalován klient systému Kerberos. Tento bal´ıˇcek obsahuje samostatné nezávislé aplikace (kinit, klist, kdestroy, kpasswd), které udrˇzuj´ı informace o l´ıstc´ıch (viz. Kerberos 5) a zprostˇredkovávaj´ı komunikaci mezi uˇzivatelem a serverem Kerberos. Dále jsou v bal´ıˇcku obsaˇzeny sd´ılené knihovny, pˇres které mohou aplikace komunikovat se serverem Kerberos. Vyuˇzit´ı tˇechto knihoven nen´ı pro programátora aplikace povinné, ale usnadˇ nuje mu v´ yraznˇe práci. Tyto knihovny zajiˇst’uj´ı autentizaci a autorizaci klienta v˚ uˇci serveru a informace o u ´spˇechu ˇci ne´ uspˇechu operace pˇredávaj´ı v´ yˇse aplikaci.

22

6.4

Programov´ e rozhran´ı aplikac´ı

Vˇsechny aplikace z bal´ıˇcku imap2006e obsahuj´ı jednotné autentizaˇcn´ı vrstvy, které udávaj´ı metodu autentizace a jej´ı zp˚ usob proveden´ı. Pokud se jedná o autentizaci pˇres systém Kerberos, mohou se jednotlivé vrstvy seˇradit hierarchicky v následuj´ıc´ım poˇrad´ı.

Obrázek 6.1: Hierarchie autentizaˇcn´ıch vrstev Jak je vidˇet z obrázku 6.1, v´ ybˇer zp˚ usobu autentizace je ekvivalentn´ı pouˇzitému autentikátoru (pro systém Kerberos: GSSAPI nebo PAM modul). U jin´ ych aplikac´ı je ˇclenˇen´ı autentizaˇcn´ıch mechanism˚ u podobné a stoj´ı proto za zm´ınku jeˇstˇe nativn´ı podpora Kerbera. Vˇsechny d˚ uleˇzité vrstvy (AUTHENTICATOR, GSSAPI, nativn´ı podpora, PAM) budou vysvˇetleny dále v textu.

Struktura Authenticator (UW) Toto jednotné rozhrann´ı bylo vytvoˇreno UW za u ´ˇcelem v´ ybˇeru autentizaˇcn´ıho mechanismu. Jak jiˇz bylo zm´ınˇeno, autentizaˇcn´ı mechanismus m˚ uˇze b´ yt ovˇeˇren´ı pomoc´ı unixového hesla, PAM modulu nebo systému Kerberos. Pokud se pod´ıváme na Authenticator z pohledu programátora, jedná se o strukturu v jazyce C, která obsahuje informace o autentizaˇcn´ı metodˇe a ukazatele na funkce, které autentizaci na stranˇe klienta a serveru provádˇej´ı. Abych ukázal konkrétn´ı pˇr´ıklad authentikátoru, demonstroval jsem vˇse na pˇr´ıkladu autentizace pomoc´ı GSSAPI. Samotn´ y Authenticator je struktura: AUTHENTICATOR { long flags; char *name; authcheck_t valid; authclient_t client; authserver_t server; AUTHENTICATOR *next; };

-

pˇr´ıznaky autentikátoru jméno autentikátoru adresa ovˇeˇrovac´ı funkce adresa klientské funkce adresa serverové funkce ukazatel na dalˇs´ı autentikátor

23

V pˇr´ıpadˇe autentikátoru pro metodu GSSAPI bude struktura definovaná následovnˇe: AUTHENTICATOR auth_gss = { AU_SECURE | AU_AUTHUSER, ‘‘GSSAPI’’, auth_gssapi_valid, auth_gssapi_client, auth_gssapi_server, NIL }; parametr auth_gss

AU_SECURE AU_AUTHUSER AU_HIDE AU_SECURE

v´ yznam jméno autentizaˇcn´ı metody, která byla vybrána pˇred samotn´ ym pˇrekladem aplikace. Jméno metody se skládá z prefixu “auth_” + “gss”. Hodnota “gss” odpov´ıdá metodˇe autentizace vybrané v hlavn´ım Makefile jako hodnota parametru PASSWDTYPE pˇr´ıznaky autentikátoru. Pomoc´ı logického souˇctu m˚ uˇze b´ yt vybrána kombinace v´ıce moˇznost´ı

bezpeˇcn´ y autentikátor, autentikátor zajiˇst’uj´ıc´ı bezpeˇcnou v´ ymˇenu hesel a bezpeˇcnou autentizaci AU_AUTHUSER obousmˇerná autentizace AU_HIDE skryt´ y autentikátor, metoda autentizace nebude zobrazena uˇzivateli ani serveru auth_gssapi_valid ovˇeˇren´ı, zda je metoda autentizace dostupná na obou stranách (klient-server) auth_gssapi_client autentizaˇcn´ı funkce pro klienta auth_gssapi_server autentizaˇcn´ı funkce pro server. Nejprve se volá funkce auth_gssapi_server na stranˇe serveru. To zp˚ usob´ı zavolán´ı funkce auth_gssapi_client na stranˇe klienta. Dále bˇeˇz´ı tyto funkce soubˇeˇznˇe a ovˇeˇruj´ı autentizaˇcn´ı u ´daje. Na konci vrac´ı u ´daje o u ´spˇechu/ne´ uspˇechu autentizace. Cel´ y proces komunikace je znázornˇen na obrázku 6.2 Funkce auth_gssapi_valid, auth_gssapi_client a auth_gssapi_server mus´ı m´ıt také pˇresnˇe definované parametry. long auth_gssapi_valid (void);

24

Obrázek 6.2: Atentizace GSSAPI - ˇcasov´ y diagram

long auth_gssapi_client ( authchallenge_t challenger, authrespond_t responder, char *service, NETMBX *mb, void *stream, unsigned long *trial, char *user );

-

funkce, pˇrij´ımaj´ıc´ı pˇr´ıchoz´ı zprávy funkce, odes´ılaj´ı zprávy název sluˇzby (IMAP, POP3...) emailová schránka, kterou chceme otevˇr´ıt aktuáln´ı spojen´ı mezi klientem a serverem poˇcet zb´ yvaj´ıc´ıch pokus˚ u o pˇrihláˇsen´ı jméno uˇzivatele

char *auth_gssapi_server ( authresponse_t responder, - funkce odes´ılaj´ıc´ı a pˇrij´ımaj´ıc´ı zprávy int argc, - poˇcet parametr˚ u pˇr´ıkazové ˇrádky char *argv[] - pole parametr˚ u pˇr´ıkazové ˇrádky );

25

Nativn´ı podpora Aplikace si ˇr´ıd´ı komunikaci se serverem Kerbera sama. Vˇsechny náleˇzitosti jako z´ıskán´ı a distribuce l´ıstk˚ u je plnˇe v moci aplikace. Toto ˇreˇsen´ı nen´ı obsaˇzeno v aplikac´ıch UW, ale je pˇr´ıtomno v bal´ıˇcku, kter´ y nab´ız´ı Massachusetts Institute of Technology (MIT) (zde byl systém Kerberos vytvoˇren).

Rozhran´ı GSSAPI GSSAPI (Generic Security Services Application Programming Interface) RFC 2744 [16] je generické aplikaˇcn´ı rozhrann´ı poskytuj´ıc´ı autentizaci klient-server. Jedná se pouze o mezivrstvu mezi aplikac´ı a autentizaˇcn´ım protokolem. Smyslem GSSAPI je poskytnout aplikaci jednotné programové rozhran´ı k r˚ uzn´ ym autentizaˇcn´ım metodám (prakticky mnohem detailnˇejˇs´ı definici rozhran´ı AUTHENTICATOR vytvoˇreného v UW). V praxi se pouˇz´ıv´ a právˇe pro autentizaci pomoc´ı Kerbera. V d˚ usledku toho, kdyˇz se o aplikaci prohlás´ı, ˇze podporuje GSSAPI, tak se mysl´ı, ˇze podporuje systém Kerberos. Mezi nejd˚ uleˇzitˇejˇs´ı funkce GSSAPI patˇr´ı: gss_acquire_cred - server zas´ılá poˇzadavek na z´ıskán´ı tzv. gss-api credential. Credential ke struktura s jedineˇcn´ ym ID. Tato struktura obsahuje informace o autentizaˇcn´ıch mechanismech klienta (v naˇsem pˇr´ıpadˇe pine). Server porovná dostupné mechanismy klienta se sv´ ymi a nab´ıdne klientovi pouˇzit´ı spoleˇcnˇe znám´ ych mechanism˚ u (ve v´ ysledku nab´ız´ı vˇetˇsinou autentizaci systémem Kerberos). gss_release_cred - zruˇsen´ı credentials gss_init_ces_context - vytvoˇren´ı bezpeˇcného spojen´ı mezi aplikac´ı a vzdálenou stranou. Funkce m˚ uˇze vrátit autentizaˇcn´ı token, kter´ y bude pˇreposlán druhému u ´ˇcastn´ıkovi. Ten token pˇredá funkci gss_accept_sec_context gss_accept_sec_context - souhlas k vytvoˇren´ı bezpeˇcného spojen´ı gss_delete_sec_context - zruˇsen´ı bezpeˇcného spojen´ı gss_wrap - pˇripojen´ı kontroln´ıho souˇctu ke zprávˇe a volitelnˇe jej´ı zaˇsifrován´ı gss_unwrap - deˇsifruje, pokud byla zpráva zaˇsifrovaná a zkontroluje kontroln´ı souˇcet, zda nebyla zpráva pozmˇenˇena

26

Demonstrujeme-li autentizaci pomoc´ı GSSAPI (Kerberos) mezi aplikacemi pine a imap, budou volán´ı d˚ uleˇzit´ ych funkc´ı ˇrazena hierarchicky v následuj´ıc´ım sledu (poˇrad´ı vˇsech volan´ ych funkc´ı je v pˇr´ıloze C): pine: auth_gssapi_valid imap: auth_gssapi_valid auth_gssapi_server gss_acquire_cred pine: auth_gssapi_client gss_init_sec_context imap: gss_accept_sec_context pine: gss_init_sec_context imap: gss_wrap pine: gss_unwrap gss_wrap gss_delete_sec_context imap: gss_unwrap gss_delete_sec_context gss_release_cred

Autentizaˇ cn´ı sch´ ema PAM PAM (Pluggable Authentication Modules) je sjednocené autentizaˇcn´ı schéma, které je implementováno v mnoha open source verz´ıch UNIXu. Je to sada sd´ılen´ ych knihoven, kter´ a umoˇzn ˇuje administrátorovi snadno (za bˇehu) pˇrizp˚ usobovat autentizaˇcn´ı sluˇzby pro r˚ uzné aplikace, a ty jiˇz tedy nemusej´ı b´ yt pˇri jakékoliv zmˇenˇe autentizaˇcn´ıch mechanism˚ u opˇetovnˇe pˇrepisovány a pˇrekompilovávány. Jedná se o modulárn´ı pˇr´ıstup k autentizaci, kter´ y vznikl jako reakce na neustále se zvyˇsuj´ıc´ı poˇcet novˇe vznikaj´ıc´ıch autentizaˇcn´ıch mechanism˚ u. Kromˇe statick´ ych hesel umoˇzn ˇuje PAM pouˇz´ıván´ı napˇr´ıklad jednorázov´ ych hesel, ˇcipov´ ych karet ˇci biometrik.

27

Shrnut´ı V této kapitole jsem popsal instalaci a konfiguraci systému pro autentizaci pomoc´ı systému Kereberos. Prozkoumal a popsal jsem autentizaˇcn´ı vrstvy aplikac´ı bal´ıˇcku imap2006e pro implementaci autentizace pˇres Kerberos. Jedn´ım z c´ıl˚ u diplomové práce je implementace nového autentizaˇcn´ıho mechanismu. Pˇred samotnou implementac´ı se mus´ım rozhodnout do jaké vrstvy aplikac´ı tento mechanismus pˇridám. V zásadˇe jsou dvˇe moˇznosti, bud’ se zamˇeˇr´ım na vrstvu PAM a nebo pˇrid´ am nov´ y mechanismu do vrstvy AUTHENTICATOR.

28

Kapitola 7

Model autentizace a autorizace uˇ zivatele v glob´ aln´ıch s´ıt´ıch Dalˇs´ı ˇcást´ı diplomové práce je návrh modelu autentizaˇcn´ıho mechanismu. Tento model by an mˇel splˇ novat urˇcité poˇzadavky definované v kapitole 7.1. V dalˇs´ıch kapitolách je pops´ cel´ y proces návrhu modelu a v´ ysledné specifikace vytvoˇren´ ych nebo pouˇzit´ ych protokol˚ u.

7.1

Poˇ zadavky

• Bezpeˇ cnost modelu – Bezpeˇcnost je jedn´ım z nejd˚ uleˇzitˇejˇs´ıch poˇzadavk˚ u. Pokud by nˇekdo dokázal z´ıskat ciz´ı uˇzivatelské jméno a heslo, dostal se tak ke sluˇzbˇe, ke kter´ ym má napaden´ y uˇzivatel pˇr´ıstup. Z toho d˚ uvodu bude na bezpeˇcnost kladena vysoká m´ıra pozornosti. • Pˇ r´ıstup login/heslo – Autentizaˇcn´ı mechanismus by mˇel vyuˇz´ıvat pˇr´ıstup klasického zadáván´ı loginu a hesla. Bude t´ım uˇzivatelské rozhran´ı nezmˇenˇeno a uˇzivatel se nebude muset uˇcit nové postupy pro autentizaci. • Autentizace a autorizace uˇ zivatele pomoc´ı d˚ uvˇ eryhodn´ e tˇ ret´ı strany – Poˇzadovaná sluˇzba nebude provádˇet sama autentizaci a autorizaci uˇzivatele. Svˇeˇr´ı tuto ˇcinnost d˚ uvˇeryhodné tˇret´ı stranˇe. • Jedno heslo k v´ıce sluˇ zb´ am – Model systému by mˇel umoˇzn ˇovat zjednoduˇsen´ı pro uˇzivatele t´ım, ˇze bude moci pˇristupovat k v´ıce sluˇzbám pˇres jedno uˇzivatelské jméno a heslo. T´ım pádem bude moci uˇzivatel zvolit sloˇzitˇejˇs´ı heslo a t´ım zv´ yˇs´ı bezpeˇcnost. • Administrace pr´ av uˇ zivatele v jednom m´ıstˇ e – Systém by mˇel vyuˇz´ıvat d˚ uvˇeryhodnou tˇret´ı stranu pro ovˇeˇrován´ı uˇzivatel˚ u. Ta bude slouˇzit jako centráln´ı spr´ ava uˇzivatelsk´ ych pˇr´ıstupov´ ych práv ke sluˇzbám. • Pˇ rimˇ eˇ ren´ e zat´ıˇ zen´ı s´ıtˇ e – Komunikace mezi ovˇeˇrovac´ım serverem, serverem s poˇzadovanou sluˇzbou a klientem nesm´ı pˇr´ıliˇs zat´ıˇzit s´ıt’. Proto bude dbáno na pˇrimˇeˇrenou sloˇzitost protokolu. • Jednoduchost komunikaˇ cn´ıho protokolu – Pˇr´ıliˇsná sloˇzitost protokolu m˚ uˇze zabránit jeho pouˇzit´ı, proto by mˇel b´ yt tak jednoduch´ y, jak to jen dovol´ı bezpeˇcnost´ı poˇzadavky. 29

7.2

Typy model˚ u komunikace

Autentizace uˇzivatele v˚ uˇci serveru pomoc´ı d˚ uvˇeryhodné tˇret´ı strany m˚ uˇze b´ yt z hlediska ˇrazen´ı jednotliv´ ych komponent (klient, server, ovˇeˇrovac´ı server) rozd´ılná. Pokud uvaˇzujeme, ˇze autentizaˇcn´ı mechanismus navrhujeme cel´ y od zaˇcátku bez dan´ ych pravidel, mus´ıme vybrat jedno z následuj´ıc´ıch tˇr´ı schémat.

Obrázek 7.1: Moˇznosti v´ ybˇeru model˚ u

KLIENT - klientská aplikace SERVER - server, kde bˇeˇz´ı poˇzadovaná sluˇzba AS - autentizaˇcn´ı a autorizaˇcn´ı server (d˚ uvˇeryhodná tˇret´ı strana) • varianta a) - Klient se nejprve autentizuje v˚ uˇci AS, kter´ y tvoˇr´ı spojovac´ı prvek mezi serverem a klientem. AS dále kontaktuje server a zprostˇredkovává následnou komunikaci. Zde se nask´ ytá dalˇs´ı moˇznost, zda toto zapojen´ı bude platit pouze pro autentizaci a autorizaci a pˇrenos dat jiˇz bude prob´ıhat pˇres pˇr´ımé spojen´ı. • varianta b) - Klient pˇristupuje pˇr´ımo k serveru a ten se ptá AS, zda tento klient je autentizován a oprávnˇen vyuˇz´ıvat sluˇzbu na serveru. Toto zapojen´ı je v praxi vyuˇz´ıváno napˇr´ıklad pro pˇr´ıstup klient˚ u k Wi-Fi s´ıti, kde jako AS m˚ uˇze slouˇzit server Radius. • varianta c) - Klient pˇristupuje nejprve k AS, zde se autentizuje, autorizuje a z´ısk´ av´ a identifikaci, d´ıky které m˚ uˇze pˇristupovat k serveru. Server si tuto identifikaci m˚ uˇze ovˇeˇrit u AS, zda je opravdu platná. Pokud ji AS potvrd´ı, server povol´ı klientovi pˇr´ıstup. Tato varianta - m´ırnˇe upravená - je vyuˇzita v systému Kerberos. 30

Vyb´ıral jsem variantu s ohledem na moˇznost zaˇclenˇen´ı nového mechanismu do stávaj´ıc´ıch aplikac´ı. Rovnˇeˇz jsem bral zˇretel na m´ıru nutn´ ych u ´prav systém˚ u pro jednotlivé moˇznosti. Po zváˇzen´ı tˇechto okolnost´ı jsem vybral variantu b). Klient bude pˇristupovat k poˇzadovanému serveru stejn´ ym zp˚ usobem, jako by ˇzádn´ y autentizaˇcn´ı server (AS) neexistoval. Server dále pˇredá pˇrihlaˇsovac´ı u ´daje AS, kter´ y klienta ovˇeˇr´ı a pˇredá serveru informace o v´ ysledku. Dále prob´ıhá komunikace jiˇz jen mezi klientem a serverem. Schéma komunikace je nyn´ı vybráno a v dalˇs´ı kapitole vytvoˇr´ım model komunikaˇcn´ıho protokolu.

7.3

N´ avrh modelu komunikace

T´ım, ˇze komunikace klient-server a server-AS bude na sobˇe nezávislá, budu moci pouˇz´ıt pro komunikaci server-AS jiˇz existuj´ıc´ı protokol. Jak jiˇz bylo zm´ınˇeno, vybraná varianta se pouˇz´ıvá pˇri ovˇeˇrován´ı uˇzivatele pomoc´ı serveru Radius ve Wi-Fi s´ıt´ıch. V mém pˇr´ıpadˇe se t´ımto inspiruji a pouˇziji protokol Radius právˇe pro komunikaci server-AS. Jediné, co bude nutné definovat, budou pˇrenáˇsené informace na cestˇe server-AS(Radius) a AS(Radius)server. Obecnˇe bude autentizace prob´ıhat následovnˇe:

Obrázek 7.2: Schéma komunikace Popis schématu: 1. klient pos´ılá autentizaˇcn´ı u ´daje serveru 2. server pˇrepos´ılá informace AS(Radius) 3. AS(Radius) zas´ılá v´ ysledek autentizace klienta 4. server odpov´ıdá klientovi “Autentizován”/“Neautentizován” Zb´ yvá jeˇstˇe navrhnout komunikaci mezi klientem a serverem. 31

7.4

N´ avrh protokolu SAUP - Single Authentication Protocol

Komunikace mezi klientem a serverem bude prob´ıhat mnou navrˇzen´ ym protokolem SAUP (Simple Authentication Protocol). Mˇela by b´ yt zabezpeˇcená a odolná v˚ uˇci u ´tok˚ um. Z toho d˚ uvodu pouˇziji ˇsifrován´ı komunikace, bude se jednat o symetrickou ˇsifru AES s délkou kl´ıˇce 128 bit˚ u. V´ ysledek návrhu je zobrazen na obrázku 7.3.

ˇ Obrázek 7.3: Casov´ y pr˚ ubˇeh komunikace

Popis komunikace SAUP protokolu: 1. Klient pos´ılá serveru login a zaˇsifrované náhodné ˇc´ıslo nonceA . Kl´ıˇcem kAB je hash zadaného hesla uˇzivatele. 2. Server potˇrebuje zjistit uˇzivatelské heslo, protoˇze je pˇri komunikaci pouˇzito k odvozen´ı ˇsifrovac´ıho kl´ıˇce kAB. Zas´ılá proto dotaz na AS(S) s informacemi: • login - pˇrihlaˇsovac´ı jméno uˇzivatele • service - jméno ˇzádaj´ıc´ı sluˇzby (napˇr´ıklad IMAP) • domain - doména, ze které se server(B) dotazuje • passwdBS - heslo, které je sd´ıleno mezi serverem(B) a AS(S) 3. AS(S) odpov´ıdá a pos´ılá kl´ıˇc kAB k ˇsifrované komunikaci klient-server. Tento kl´ıˇc se nezas´ılá v otevˇrené podobˇe, ale je zaˇsifrován tajn´ ym kl´ıˇcem kB, kter´ y zná pouze server(B). AS(S) se o ˇsifrován´ı kl´ıˇce kAB nestará, protoˇze ho má jiˇz zaˇsifrovan´ y ve své databázi ve formˇe cryptkB (kAB). 4. Server(B) si rozˇsifruje kl´ıˇc kAB a pomoc´ı nˇej zjist´ı náhodné ˇc´ıslo nonceA . Vygeneruje si své náhodné ˇc´ıslo nonceB a spoj´ı s ˇc´ıslem nonceA v poˇrad´ı nonceB , nonceA . Spojené ˇc´ıslo nonceBA zaˇsifruje a zaˇsle klientovi. 32

5. Klient pomoc´ı kl´ıˇce kAB deˇsifruje zprávu a zjist´ı náhodné ˇc´ıslo nonceB 6. Klient zaˇsle serveru(B) v otevˇrené podobˇe náhodné ˇc´ıslo nonceB . Pokud náhodné ˇc´ıslo nonceB odpov´ıdá tomu ˇc´ıslu, které server(B) vygeneroval, pak probˇehla autentizace u ´spˇeˇsnˇe. 7. Server(B) pos´ılá zprávu klientovi o u ´spˇechu/ne´ uspˇechu autentizace.

Popis zpr´ avy protokolu SAUP Protokol SAUP dˇel´ı zprávu na dvˇe ˇcásti: hlaviˇcku a data. Hlaviˇ cka protokolu SAUP:

Obrázek 7.4: Hlaviˇcka protokolu SAUP

Pole pˇr´ıznak˚ u: • 2 bity - rezervováno • 2 bity - typ zprávy • 3 bity - nevyuˇzito • 1 bit - RES - v´ ysledek autentizace auth_ok / auth_failed Délka zprávy - Obsahuje délku zprávy (hlaviˇcka + data) v bajtech. Data následuj´ı bezprostˇrednˇe za hlaviˇckou.

Datov´ aˇ c´ ast SAUP:

Obrázek 7.5: Datová ˇcást protokolu SAUP

Protokol SAUP umoˇzn ˇuje pˇrenáˇset v jedné zprávˇe v´ıce atribut˚ u najednou. Kaˇzd´ y atribut je tvoˇren dvojic´ı délka, data. Maximáln´ı velikost pˇrenáˇsen´ ych dat je 64kB - délka hlaviˇcky. Poˇcet pˇrenáˇsen´ ych atribut˚ u nen´ı v principu omezen, pouze plat´ı omezen´ı velikosti celkov´ ych pˇrenáˇsen´ ych dat. Nicménˇe stále plat´ı pravidlo daného obsahu zprávy podle typu zprávy. 33

7.5

Vytvoˇ ren´ı ˇ sifrovac´ıho kl´ıˇ ce kAB

Protokol SAUP pouˇz´ıvá pro zabezpeˇcen´ı komunikace symetrickou ˇsifru AES v reˇzimu CBC. Vˇsechny chránˇené poloˇzky zpráv mezi klientem a serverem jsou ˇsifrovány jedn´ım kl´ıˇcem. ˇ Sifra AES vyuˇz´ıvá kl´ıˇc dlouh´ y 128 bit˚ u. Kl´ıˇc komunikace protokolu SAUP se nepˇrenáˇs´ı po s´ıti. Na stranˇe klienta je vygenerov´ an ze zadaného uˇzivatelského hesla. Na stranˇe serveru je z´ıskán od AS(S). Generován´ı kl´ıˇce na stranˇe klienta: 1. Ze zadaného hesla se vypoˇc´ıtá SHA-1 hash. V´ ysledkem je 160ti bitov´ y kód. 2. Vypoˇc´ıtan´ y kód se zkrát´ı useknut´ım prav´ ych 32 bit˚ u na celkovou délku 128 bit˚ u. V´ ysledkem je ˇsifrovac´ı kl´ıˇc kAB .

Z´ıskán´ı kl´ıˇce na stranˇe serveru: 1. Server poˇsle dotaz na AS(S) s autentizaˇcn´ımi u ´daji: login, service, domain, passwdBS (jednotlivé poloˇzky byly vysvˇetlen´ y dˇr´ıve). 2. Pokud server vyhodnot´ı autentizaˇcn´ı u ´daje jako nesprávné, zaˇsle zpˇet zprávu AccessReject. Pokud autentizaˇcn´ı u ´daje souhlas´ı zaˇsle zprávu Access-Accept. Souˇcást´ı této zprávy je i atribut s obsahem zaˇsifrovaného kl´ıˇce cryptBS (SSHA−1 ). SSHA−1 je kl´ıˇc pouˇzit´ y pro ˇsifrován´ı komunikace klient-server. Kl´ıˇc BS pro deˇsifrován´ı zná pouze server(B). AS(S) tento kl´ıˇc BS znát nemus´ı (nesm´ı), protoˇze do jeho databáze byl vloˇzen kl´ıˇc jiˇz zaˇsifrovan´ y pˇr´ımo ve formˇe cryptBS (SSHA−1 ).

34

7.6

Typy zpr´ av protokolu SAUP

Protokol SAUP zná ˇctyˇri druhy zpráv (viz. obrázek 7.3). Typická komunikace mezi klientem a serverem je znázornˇena na obrázku 7.8

Obrázek 7.6: Typy zpráv protokolu SAUP

Auth-Request Klient pos´ılá poˇzadavek na autentizaci (obrázek 7.3 - zpráva ˇc. 1). Nese informace o uˇzivatelském jménˇe a zaˇsifrované náhodné ˇc´ıslo.

Auth-Challenge Server zjist´ı u AS ˇsifrovac´ı kl´ıˇc pro daného uˇzivatele. Rozˇsifruje pˇrijaté náhodné ˇc´ıslo, pˇrid´ a k nˇemu své vygenerované náhodné ˇc´ıslo, zaˇsifruje spoleˇcn´ ym sd´ılen´ ym kl´ıˇcem a odeˇsle zpˇet klientovi (obrázek 7.3 - zpráva ˇc. 4)

35

Auth-Verify Klient rozˇsifruje zprávu a zaˇsle serveru z´ıskané náhodné ˇc´ıslo v otevˇrené podobˇe (obrázek 7.3 - zpráva ˇc. 5)

Auth-Response Server zas´ılá klientovi v´ ysledek autentizace (obrázek 7.3 - zpráva ˇc. 6). Pˇr´ıznak RES je pouˇzit pro informaci o v´ ysledku autentizace. V pˇr´ıpadˇe chybné autentizace je souˇcást´ı AuthResponse i atribut nesouc´ı informaci pro uˇzivatele o d˚ uvodu chybné autentizace. RES - 1 ... autentizace u ´spˇeˇsná RES - 0 ... autentizace ne´ uspˇeˇsná

´ eˇsná autentizace Obrázek 7.7: Uspˇ

Obrázek 7.8: Ne´ uspˇeˇsná autentizace

36

7.7

Protokol Radius

Protokol Radius je definován v RFC 2865 [14] a je vyuˇzit´ y pro komunikaci server-AS(S). Jediné, co je zde nutné zm´ınit, je definice pˇrenáˇsen´ ych atribut˚ u. Jelikoˇz jsem pro pˇrenos nˇekter´ ych autentizaˇcn´ıch informac´ı (service, domain, cryptBS (SSHA−1 )) nevyuˇzil pˇreddefinované atributy protokolu Radius, nadefinoval jsem si proto své vlastn´ı. Promˇ enn´ a service domain cryptBS (SSHA−1 )

Atribut Service Domain Service-User-Password

Typ string string string

Pˇreddefinované atributy User-Name a User-Password byly pouˇzity pro pˇrenos promˇenné login a passwdBS .

7.8

Model syst´ emu v praxi

Jak bude vypadat model systému pro jednu sluˇzbu bylo zm´ınˇeno v pˇredchoz´ıch odstavc´ıch. Nyn´ı nast´ın´ım model systému se zapojen´ım v´ıce sluˇzeb. Uˇzivatel potˇrebuje pˇristupovat k autorizované ˇcásti webového serveru, imap serveru a ftp serveru. Zapojen´ı systému je ukázáno na následuj´ıc´ım obrázku:

Obrázek 7.9: Zapojen´ı systém˚ u

Rozm´ıstˇ en´ı d˚ uvˇ ern´ ych informac´ı (kl´ıˇ c˚ u a hesel): • klient (uˇzivatel) – login - uˇzivatelské jméno – heslo - z hesla se vygeneruje kl´ıˇc keyAB pro ˇsifrován´ı komunikace

37

• server (sluˇzba imap, www, ftp) – hesloBS - heslo pro pˇr´ıstup k Radius serveru (pro kaˇzdou sluˇzbu jiné). Slouˇz´ı pro autentizaci sluˇzby v˚ uˇci serveru Radius (standardn´ı pouˇzit´ı). – kl´ıˇckBS - kl´ıˇc pro deˇsifrován´ı uˇzivatelského hesla cryptkBS (keyAB ) z´ıskaného z Radius serveru • AS (S) – hesloBS - kaˇzdé sluˇzbˇe pˇr´ısluˇs´ı jedno heslo (standardnˇe pouˇz´ıvaná hesla pro server Radius) – cryptkB (keyAB ) - zaˇsifrovan´ y kl´ıˇc cryptkB (keyAB ). Pos´ılá se sluˇzbˇe, která ho deˇsifruje pomoc´ı kB a pouˇzije pro ˇsifrován´ı komunikace s klientem. Zp˚ usoby ˇ sifrov´ an´ı komunikace: • klient(A)-server(B) — pro ˇsifrován´ı je pouˇzit SHA-1 hash z uˇzivatelského hesla • server(B)-AS(S) — komunikace nen´ı zabezpeˇcena. Pouze pro pˇredán´ı hesla serveru Radius je pouˇzit jeho MD5 souˇcet. Pˇrenáˇsené heslo cryptkBS (keyAB ) je uloˇzené na stranˇe Radius serveru jiˇz zaˇsifrované pomoc´ı kl´ıˇce kBS, tud´ıˇz je neˇcitelné.

38

Kapitola 8

Implementace V této kapitole bude popsán zp˚ usob implementace modelu navrˇzeného schématu autentizace. Cel´ y proces autentizace bude implementován do aplikac´ı pine a imapd. Tyto aplikace jsou napsány pro systém unix v programovac´ım jazyce C.

8.1

Pouˇ zit´ y software

Pouˇzité nástroje pro implementaci byly dostateˇcnˇe platformˇe pˇrenositelné, proto jsem nevyuˇzil globáln´ı s´ıt’ PlanetLab ale implementoval jsem systém v klasické TCP/IP s´ıti. Zdroje bal´ıˇck˚ u jsou uvedeny v sekci Pˇr´ıloha A. Cel´ y systém jsem implementoval na virtuáln´ım stroji VMware Player s operaˇcn´ım systémem Fedora6. Jako emailov´ y server byl pouˇzit´ y imapd z bal´ıˇcku imap-2006e vytvoˇren´ y na University of Washington. Emailov´ y klient byl pine z bal´ıˇcku pine4.64. Pro autentizaˇcn´ı a autorizaˇcn´ı server byl pouˇzit FreeRadius. Pro komunikaci se serverem Radius jsem pouˇzil a upravil knihovnu RadiusClient. Pro ˇsifrován´ı komunikace byla vyuˇzita knihovna openssl.

8.2

´ Uprava software

Pˇred samotnou implementac´ı autentizaˇcn´ıho mechanismu bylo nutné rozhodnout, do které vrstvy bude mechanismus pˇridán. Pˇr´ıpadnˇe kter´ y stávaj´ıc´ı mechanismus (napˇr´ıklad GSSAPI) bude pozmˇenˇen, pokud by pˇridán´ı nové metody nebylo moˇzné. Po prozkoumán´ı vrstvy AUTHENTICATOR jsem se rozhodl, ˇze stávaj´ıc´ı mechanismy nechám beze zmˇeny a pouze pˇridám nov´ y. T´ım budou vˇsechny zp˚ usoby autentizace st´ ale dostupné. Po pˇridán´ı mechanismu bude struktura autentizaˇcn´ıch vrstev oproti nezmˇenˇené verzi (obrázek 6.1) rozˇs´ıˇrena o autentizaci DIP (obrázek 8.1). DIP je právˇe typ autentizace vyuˇz´ıvaj´ıc´ı protokol SAUP.

39

Obrázek 8.1: Nová hierarchie autentizaˇcn´ıch vrstev

Pˇ rid´ an´ı nov´ e autentizaˇ cn´ı metody Následuj´ıc´ı u ´pravy budou prob´ıhat ve zdrojov´ ych kódech bal´ıˇck˚ u imap-2006e a pine4.64. Aplikace imapd i pine pouˇz´ıvaj´ı pro metody autentizace spoleˇcné rozhran´ı AUTHENTICATOR. Zdrojové kódy této vrstvy jsou spoleˇcné pro obˇe aplikace, proto bude staˇcit, kdyˇz postup u ´prav zm´ın´ım jen jednou pro bal´ıˇcek imap-2006e. Bude to ovˇsem myˇsleno tak, ˇze ty samé u ´pravy jsou potˇreba i na stranˇe bal´ıˇcku pine4.64. Pˇridávaná metoda má název DIP, proto toto slovo bude vkládáno vˇsude tam, kde bude jméno metody vyˇzadované. Je nutné vytvoˇrit v adresáˇri imap-2006e následuj´ıc´ı soubory: src/c-client/auth_dip.c src/osdep/unix/ckp_dip.c

Oba soubory jsem vytvoˇril jako kopie tˇechto soubor˚ u vyuˇzit´ ych pro metodu GSS (auth gss.c, ckp gss.c). Soubor ckp gss.c slouˇz´ı jen pro kontrolu hesla uˇzivatele, pˇred jeho samotn´ ym pouˇzit´ım pˇri autentizaci. V mém pˇr´ıpadˇe ˇzádná poˇcáteˇcn´ı kontrola hesla neexistuje, proto jsem tento soubor v´ yraznˇe zjednoduˇsil. V souboru auth dip.c je uloˇzen cel´ y autentizaˇcn´ı mechanismus. Tento soubor obsahuje definici jednotliv´ ych funkc´ı rozhran´ı AUTHENTICATOR (viz. 6.4). • auth_dip_valid - je prázdná - ˇzádná kontrola pˇred samotnou autentizac´ı neprob´ıh´ a • auth_dip_client - zajiˇst’uje autentizaci klienta • auth_dip_server - je volána na stranˇe serveru. V této funkci je definována i komunikace mezi serverem(B) a AS(Radius). Pro komunikaci pomoc´ı protokolu Radius jsem pouˇzil knihovnu RadiusClient, kterou jsem upravil pro potˇreby nového autentizaˇcn´ıho mechanismu. Detailnˇeji nebudu dále implementaci tˇechto dvou soubor˚ u popisovat. Pˇresné informace jsou k nalezen´ı v komentáˇr´ıch ve zdrojov´ ych kódech. 40

Bylo nutné pˇridat nov´ y mechanismus do kompilace aplikace - u ´prava souboru: imap-2006e/src/osdep/unix/Makefile: ˇrádek 892: pˇridat kompilaci souboru auth_dip.c auth_ext.c auth_gss.c auth_log.c auth_md5.c auth_pla.c auth_dip.c ˇrádek 989: za c´ıl ckpgss pˇridat c´ıl ckpdip: ckpdip: @echo Authentication DIP $(LN) ckp_dip.c osdepckp.c

V tomto stavu jsou aplikace schopny autentizace pomoc´ı mechanismu DIP. Zb´ yvá pouze tento mechanismus nastavit jako poˇzadovan´ y. Autentizaˇcn´ı mechanismus si definuje server imapd, klientská aplikace pine vybere mechanismus podle poˇzadavk˚ u serveru. U serveru imapd se volba autentizaˇcn´ıho mechanismu neprovád´ı v ˇzádném konfiguraˇcn´ım souboru n´ ybrˇz je dána parametry definovan´ ymi v souboru Makefile. Server imapd tud´ıˇz nepodporuje zmˇenu mechanismu bez nutnosti kompilace. Nastaven´ı autentizaˇ cn´ıho mechanismu: imap-2006e/Makefile: ˇrádek 165: nastavit zp˚ usob autentizace PASSWDTYPE=dip

Nyn´ı je autentizaˇcn´ı metoda pˇridána a je nastaveno jej´ı pouˇzit´ı.

8.3

Knihovna libdip service.so

Autentizaˇcn´ı mechanismus je uloˇzen v souboru auth_dip.c. Bylo by ale krajnˇe nevhodné do tohoto souboru psát definice vˇsech podp˚ urn´ ych funkc´ı. Pokud jeˇstˇe vezmeme z u ´vahu to, ˇze souˇcást´ı mechanismu je komunikace protokolem Radius, bylo by mnoˇzstv´ı programového kódu ne´ unosné. Proto jsem vytvoˇril knihovnu libdip service.so, která veˇskeré podp˚ urné operace zajiˇst’uje. Jej´ı souˇcást´ı je upravená implementace RadiusClient (Pˇr´ıloha A) pro komunikaci protokolem Radius. Obsahuje také dalˇs´ı funkce potˇrebné pro autentizaci jako ˇsifrován´ı a deˇsifrován´ı zprávy nebo ovˇeˇren´ı uˇzivatelského jména a hesla. Rozhran´ı knihovny je navrˇzeno tak, ˇze pokud nebude udˇelána v´ yznamná zmˇena do schématu komunikace protokolem SAUP, nebude nutné znovu kompilovat celou aplikaci, ale bude staˇcit aktualizace sd´ılené knihovny libdip service.so. Jednou z takov´ ych u ´prav m˚ uˇze b´ yt napˇr´ıklad zmˇena ˇsifrovac´ıho algoritmu nebo zmˇena délky ˇsifrovac´ıho kl´ıˇce.

41

Rozhran´ı knihovny libdip service.so: Knihovna libdip service.so poskytuje funkce pˇr´ımo ekvivalentn´ı zprávám SAUP protokolu. ATTRIBUTE * dip_auth_request( char * login, char * passwd ) login - uˇzivatelské jméno passwd - heslo funkce vrac´ı pˇr´ımo datagram protokolu SAUP, kter´ y se pos´ılá po s´ıti ATTRIBUTE * dip_auth_challenge( ATTRIBUTE * PDU ) PDU - datagram, kter´ y byl vytvoˇren funkc´ı dip_auth_request funkce vrac´ı pˇr´ımo datagram protokolu SAUP, kter´ y se pos´ılá po s´ıti ATTRIBUTE * dip_auth_verify( ATTRIBUTE * PDU ) PDU - datagram, kter´ y byl vytvoˇren funkc´ı dip_auth_challenge funkce vrac´ı pˇr´ımo datagram protokolu SAUP, kter´ y se pos´ılá po s´ıti ATTRIBUTE * dip_auth_response( ATTRIBUTE * PDU ) PDU - datagram, kter´ y byl vytvoˇren funkc´ı dip_auth_verify funkce vrac´ı pˇr´ımo datagram protokolu SAUP, kter´ y se pos´ılá po s´ıti int get_response ( ATTRIBUTE * PDU ) PDU - datagram, kter´ y byl vytvoˇren funkc´ı dip_auth_response funkce vrac´ı hodnotu: 0 - pokud uˇzivatel nebyl autentizován 1 - pokud uˇzivatel byl u ´spˇeˇsnˇe autentizován

8.4

Instalace

Chceme-li pouˇz´ıvat autentizaci pomoc´ı metody DIP pro emailov´ y server imapd a klient pine, je nutné nainstalovat následuj´ıc´ı bal´ıˇcky (pˇresn´ y popis instalace je popsán v pˇr´ıloze A). poˇ stovn´ı server postfix postfix-2.3.3-2 pcre-6.6-1.1 maildop-2.0.3 imap server xinetd-2.3.14-8 imap-2006e-dip – upraven´ y bal´ıˇcek (souˇcást´ı pˇriloˇzeného CD-R, instalace podle pˇr´ılohy) emailov´ y klient pine pine-4.64-dip – upraven´ y bal´ıˇcek (souˇcást´ı pˇriloˇzeného CD-R, instalace podle pˇr´ılohy)

42

knihovna libdip service.so dip-1.0 Postup instalace knihovny libdip service.so: $ cd dip $ make $ make install Radius server freeradius-1.1.4 Postup instalace: $ yum install freeradius spuˇstˇen´ı skriptu pro upraven´ı nastaven´ı serveru Radius. Pˇrizp˚ usoben´ı pro autentizaci pomoc´ı autentizaˇcn´ı metody DIP $ ./update_radius.sh - skript je souˇcást´ı pˇriloˇzeného CD-R

8.5

Konfigurace

Konfigurace systému se dá rozdˇelit na tˇri ˇcásti. Konfigurace klienta, sluˇzby a Radius serveru.

Klient Na stranˇe klienta nen´ı potˇreba nic nastavovat. Klient jen vypln´ı v pˇrihlaˇsovac´ım formul´ aˇri programu pine uˇzivatelské jméno a heslo.

Sluˇ zba - server(B) Na serveru, kde bˇeˇz´ı sluˇzba (napˇr. imap), mus´ı b´ yt nakonfigurovan´ y radius-klient. Nejdˇr´ıve je nutné nastavit pˇr´ıstupová práva k adresáˇri /usr/local/etc/raddb a jeho soubor˚ um. Pˇr´ıstup mus´ı b´ yt udˇelen pouze uˇzivateli, pod kter´ ym bˇeˇz´ı sluˇzba (napˇr. imap), protoˇze v souborech jsou uloˇzena hesla pro pˇr´ıstup k Radius serveru (tento zp˚ usob uchov´ an´ı tajné informace je u serveru Radius standardn´ı). $ chown -R imap /usr/local/etc/raddb $ chmod -R 600 /usr/local/etc/raddb

# pˇ r´ ıpadn´ a zmˇ ena vlastn´ ıka souboru # zmˇ ena pˇ r´ ıstupov´ ych pr´ av

$ vim /usr/local/etc/raddb/server # sd´ ılen´ e heslo mezi radius-klientem(imap) a radius-serverem(AS). localhost testing123

43

$ vim /usr/local/etc/raddb/radiusclient.conf # adresa Radius serveru authserver localhost # kl´ ıˇ cBS pro deˇ sifrov´ an´ ı uˇ zivatelsk´ eho kl´ ıˇ ceAB # (kter´ y se pouˇ z´ ıv´ a ke komunikaci klient-server) service_radius_passwd klicBS

Radius - AS(S) Nastaven´ı Radius serveru. Nejprve je potˇreba nastavit adresu z které se sluˇzba (imap) bude pˇrihlaˇsovat. Toto se nastavuje v souboru /etc/raddb/clients.conf. Editace uˇzivatel˚ u se mus´ı provádˇet ruˇcnˇe v souboru /etc/raddb/users. $ vim /etc/raddb/clients.conf client 127.0.0.1 { secret = testing123 shortname = localhost

# # # #

adresa serveru, kde bˇ eˇ z´ ı sluˇ zba sd´ ılen´ e heslo mezi radius-klientem a radius-serverem intern´ ı pojmenov´ an´ ı adresy

} Nastaven´ı uˇzivatele username: Nastaven´ı se skládá ze dvou ˇcást´ı. Prvn´ı je autentizaˇcn´ı ˇcást (prvn´ı dva ˇrádky). Je to podm´ınka, kterou mus´ı klient splnit (zadat shodné u ´daje). Po posled-n´ım argumentu bez ˇcárky (v tomto pˇr´ıpadˇe je posledn´ı argument Domain == “localhost”) následuje odpovˇed’ klientovi. Zde je nastavené zaˇsifrované heslo pro komunikaci klient(pine)server(imap). Toto heslo se z´ıská pomoc´ı programu genDipKey, kter´ y je souˇcást´ı instalace knihovny libdip service.so. Heslo se vygeneruje na stranˇe serveru(imap) a uloˇz´ı se do tohoto souboru. Heslo je ve formˇe hexa znak˚ u. username Auth-Type := Local, User-Password == ‘‘klicBS’’, Service == ‘‘IMAP’’, Domain == ‘‘localhost’’ Reply-Message = ‘‘HELLO %u’’, Service-User-Password = ‘‘00112233445566778899aabbccddeeff’’

44

Kapitola 9

Bezpeˇ cnost syst´ emu M´ıra bezpeˇcnosti systému je dána jeho nejslabˇs´ı ˇcást´ı. Proto je nutné brát v u ´vahu jak komunikaˇcn´ı protokol, tak i jeho implementaci. Nebot’ chyba v implementaci zabezpeˇceného protokolu m˚ uˇze u ´toˇcn´ıkovi umoˇznit pˇr´ıstup k systému, nebo krádeˇz d˚ uvˇern´ ych informac´ı, ’ at uˇz uˇzivatelsk´ ych dat nebo pˇr´ıstupov´ ych hesel.

9.1

Bezpeˇ cnost protokolu SAUP

Zkoumal jsem základn´ı moˇzné u ´toky, které mohou b´ yt na protokol provedeny a nenalezl jsem jedinou moˇznost, kdy by u ´toˇcn´ık mohl z komunikace odposlechnout heslo nebo mu bylo umoˇznˇeno neoprávnˇené autentizace. Neuvaˇzoval jsem situace, kdy u ´toˇcn´ık pozmˇen´ı kód klientské aplikace, kter´ y mu umoˇzn´ı z´ıskat uˇzivatelské jméno a heslo. Tento u ´tok by byl totiˇz moˇzn´ y na jak´ ykoliv systém. D´ ale jsem také poˇc´ıtal s t´ım, ˇze pouˇzité ˇsifrovac´ı algoritmy jsou bezpeˇcné. Pˇri anal´ yze bezpeˇcnosti ˇslo pouze o bezpeˇcnost navrhnutého komunikaˇcn´ıho protokolu. Uvaˇzoval jsem následuj´ıc´ı moˇznosti:

Obrázek 9.1: M´ısta moˇzného u ´toku

45

1. Snaha o prolomen´ı na stranˇe klienta. Na stranˇe klienta nejsou uloˇzena ˇzádná d˚ uvˇern´ a data. Pokud se u ´toˇcn´ık bude vydávat za uˇzivatele, pokus´ı se pˇrihlásit jeho uˇzivatelsk´ ym jménem, nepodaˇr´ı se mu zjistit heslo, protoˇze server(B) rozˇsifruje náhodné ˇc´ıslo nonceA jako jiné náhodné ˇc´ıslo nonceA’ a to vrát´ı zpˇet zaˇsifrované. Proto je zde moˇzn´ y pouze u ´tok silou na ˇsifrovac´ı algoritmus. ´ “Man In The Middle”. Tento u ´tok je nemoˇzn´ y bez znalosti ˇsifrovac´ıho kl´ıˇce. 2. Utok ´ Utoˇcn´ık má témˇeˇr ty samé moˇznosti jako v prvn´ım pˇr´ıpadˇe. ´ cn´ık se vydává za faleˇsn´ 3. Snaha o prolomen´ı na stranˇe serveru(B). Utoˇ y server(B). Pˇri komunikaci s klientem má u ´toˇcn´ık prakticky stejné ˇsance jako v situaci, kdyˇz se vydával za klienta. Pˇri komunikaci s AS(S) mus´ı zadat heslo, které zná “prav´ y” server(B). I kdyˇz by se mu to povedlo, tak z´ıská zaˇsifrovan´ y kl´ıˇc cryptBS (SSHA−1 ) pro komunikaci s klientem. Deˇsifrován´ı tohoto kl´ıˇce komunikace bez znalosti kl´ıˇce BS vede zase jen k u ´toku silou. Nebezpeˇc´ı by bylo, pokud by u ´toˇcn´ık z´ıskal neoprávnˇen´ y pˇr´ıstup k serveru(B) skrze uˇzivatele, pod kter´ ym napadená sluˇzba bˇeˇz´ı. Mohl by pak z´ıskat ˇsifrovac´ı kl´ıˇc ke komunikaci jak ke klientovi tak i s AS(Radius). Tato moˇznost ale nen´ı otázkou bezpeˇcnosti protokolu, ale sp´ıˇse bezpeˇcnosti systému, na kterém sluˇzba bˇeˇz´ı. ´ ´ cn´ık m˚ 4. Utok “Man In The Middle”. Utoˇ uˇze odposlechnout a pozmˇenit zaˇsifrovanou verzi kl´ıˇce cryptBS (SSHA−1 ). Toto povede k chybné autentizaci uˇzivatele, ale neumoˇzn´ı u ´toˇcn´ıkovi z´ıskat d˚ uvˇerná data. ´ cn´ık má témˇeˇr stejné ˇsance jako v pˇredchoz´ım 5. Snaha o prolomen´ı na stranˇe AS(S). Utoˇ pˇr´ıpadˇe

9.2

Kvalita implementace

Pˇri implementaci autentizaˇcn´ıho mechanismu a knihovny libdip service.so jsem se snaˇzil vyvarovat chyb vedouc´ıch k prolomen´ı pˇr´ıstupu k systému. Nejnebezpeˇcnˇejˇs´ı m´ısto komunikace celého systému se tak stává server(B). Na serveru(B) je uloˇzené pˇr´ıstupové heslo k AS v konfiguraˇcn´ım souboru, kter´ y je pˇr´ıstupn´ y pouze uˇzivateli, pod kter´ ym sluˇzba bˇeˇz´ı. V tom samém souboru je také uloˇzen kl´ıˇc BS , kter´ y se pouˇz´ıvá pro deˇsifrován´ı kl´ıˇce komunikace klient-server. Pokud by doˇslo k chybné konfiguraci práv k tomuto souboru, mohl by u ´toˇcn´ık, kter´ y by mˇel pˇr´ıstup na server(B), z´ıskat kl´ıˇce komunikace a d˚ uvˇerná data uˇzivatel˚ u.

46

Kapitola 10

Z´ avˇ er Pˇredmˇetem diplomové práce byl návrh modelu autentizace a autorizace uˇzivatele pomoc´ı d˚ uvˇeryhodného serveru. Nejprve jsem zde uvedl teoretick´ y základ vysvˇetluj´ıc´ı danou problematiku. Analyzoval jsem systém autentizace Kerberos a ze z´ıskan´ ych informac´ı jsem vycházel pˇri návrhu autentizaˇcn´ıho mechanismu. V´ ysledkem návrhu bylo schéma komunikace klient - server(sluˇzba) autentizaˇcn´ı server. Pro komunikaci mezi klientem a serverem(sluˇzbou) jsem vytvoˇril nov´ y protokol SAUP (Single Authentication Protocol), pro pˇredáván´ı dat mezi serverem(sluˇzbou) a autentizaˇcn´ım serverem byl pouˇzit´ y protokol Radius. Navrˇzen´ y model autentizace jsem u ´spˇeˇsnˇe implementoval do aplikac´ı emailového klienta pine a poˇstovn´ıho serveru imap. Pˇri návrhu a implementaci modelu systému byl kladen velk´ y d˚ uraz na zabezpeˇcen´ı pˇrenosu autentizaˇcn´ıch informac´ı. V posledn´ı kapitole jsem rozeb´ıral r˚ uzné druhy u ´tok˚ u na protokol SAUP a neshledal jsem ˇzádné kritické m´ısto, kde by u ´toˇcn´ık mohl odposlechnout a rozluˇstit pˇrenáˇsené informace. Navrˇzen´ y model slouˇz´ı jako základ autentizaˇcn´ıho mechanismu. Existuje mnoho moˇznost´ı, které by mohly rozˇs´ıˇrit jeho funkˇcnost. Mohlo by se jednat a ˇsirˇs´ı podporu ˇsifrovac´ıch algoritm˚ u, schopnost jednat s v´ıce druhy autentizaˇcn´ıch server˚ u (napˇr. ldap), vyhled´ an´ı sekundárn´ıho autentizaˇcn´ıho serveru pˇri nedostupnosti primárn´ıho. Asi nejvˇetˇs´ı inovac´ı by byl pˇrechod na dynamickou zmˇenu hesel pouˇzit´ ych pro ˇsifrován´ı komunikace. Tato varianta by ovˇsem znamenala zásah i na stranˇe klienta. Musela by se pˇridat nová vrstva mezi uˇzivatele a klientskou aplikaci, která by zajiˇst’ovala konverzi uˇzivatelského hesla na dynamické heslo pro ˇsifrován´ı komunikace.

47

Literatura [1] Libor Dostálek a kolektiv. Velký pr˚ uvodce protokoly TCP/IP: Bezpeˇcnost. Computer Press, 2003. [2] B. Aboba and J. Wood. RFC 3539: Authentication, Authorization and Accounting (AAA) Transport Profile, 2003. [3] L. Blunk and J. Vollbrecht. RFC 2284: PPP Extensible Authentication Protocol (EAP), 1998. [4] Radim Bárt˚ u. Semestráln´ı práce z pˇredmˇetu KIV/Pˇrenos dat. http://www.kiv.zcu.cz/~simekm/vyuka/pd/zapocty-2004/802 1x-bartu/index.php, 2005. [5] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, and J. Arkko. RFC 3588: Diameter Base Protocol, 2003. [6] P. Congdon, B. Aboba, A. Smith, G. Zorn, and J. Roese. RFC 3580: IEEE 802.1X Remote Authentication Dial In User Service (RADIUS), 2003. [7] G. De Laet and G. Schauwers. Network Security Fundamentals. Cisco Press, 2005. [8] Companion Guide. Fundamentals of Network Security. Cisco Press, 2004. [9] J. Kohl and C. Neuman. RFC 1510: The Kerberos Network Authentication Service (V5). ftp://ftp.rfc-editor.org/in-notes/rfc1510.txt, 1993. [10] Jakub Mahdal. Kerberos, PAM. http://www.fi.muni.cz/~kas/p090/referaty/2005-podzim/st/kerberos pam.html, 2005. [11] C. Rigney. Rfc 2059: Radius accounting, 1997. [12] C. Rigney. RFC 2866: RADIUS Accounting, 2000. [13] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Rfc 2058: Remote authentication dial in user service (radius), 1997. [14] C. Rigney, S. Willens, A. Rubens, and W. Simpson. RFC 2865: Remote Authentication Dial In User Service (RADIUS), 2000. [15] W. Simpson. RFC 1661: Point-to-Point Protocol, 1994. [16] J. Wray. RFC 2744: Generic Security Service API Version 2: C-bindings, 2003.

48

Dodatek A

Instalace Zdroje V diplomové práci byly uvedeny odkazy na následuj´ıc´ı zdroje: imap2006e ftp://ftp.cac.washington.edu/imap/old/imap-2006e.tar.Z pine4.64 ftp://ftp.cac.washington.edu/pine/pine.tar.gz VMware Player http://www.vmware.com/download/player/ Fedora6 http://www.thoughtpolice.co.uk/vmware/http download.php?file=fedora-fc6-i386.zip FreeRadius ftp://ftp.freeradius.org/pub/radius/old/freeradius-1.1.4.tar.gz RadiusClient ftp://ftp.cityline.net/pub/radiusclient/radiusclient-0.3.2.tar.gz openssl http://www.openssl.org/source/openssl-0.9.8e.tar.gz

49

Popis instalace na operaˇcn´ı systém Fedora6 (Pˇr´ıloha A). Operaˇcn´ı systém byl spuˇstˇen v aplikaci VMware Player.

Instalace Instalace pˇ rekladaˇ ce GCC - GNU Compiler Collection $ yum install gcc $ yum install gcc-c++.i386

Kerberos a poˇ zadovan´ e knihovny nebo aplikace $ $ $ $ $ $

wget http://www.openssl.org/source/openssl-0.9.8e.tar.gz gunzip openssl-0.9.8e.tar.gz tar xvf openssl-0.9.8e.tar ./config make su: make install

$ $ $ $ $ $

wget http://ftp.gnu.org/pub/gnu/ncurses/ncurses-5.5.tar.gz gunzip ncurses-5.5.tar.gz tar xvf ncurses-5.5.tar ./configure make su: make install

$ yum install byacc $ yum install flex $ wget http://download.talinux.tal.org/pub/talinux/sources-current-unstable /security/libsepol/libsepol-1.14.tgz $ tar xvf libsepol-1.14.tgz $ make $ su: make install

50

$ $ $ $

wget http://www.nsa.gov/selinux/archives/checkpolicy-1.34.1.tgz tar xvf checkpolicy-1.34.1.tgz make su: make install

$ $ $ $

wget http://www.nsa.gov/selinux/archives/libselinux-1.34.7.tgz tar xvf libselinux-1.34.7.tgz make su: make install

$ wget http://www.kernel.org/pub/linux/libs/pam/pre/library /Linux-PAM-0.99.7.1.tar.bz2 $ tar xvf Linux-PAM-0.99.7.1.tar.bz2 $ ./configure $ make $ su: make install (s verz´ ı 0.99.4.0 neˇ slo pˇ reloˇ zit)

$ $ $ $ $ $ $

wget http://web.mit.edu/Kerberos/dist/krb5/1.6/krb5-1.6.1-signed.tar tar xvf krb5-1.6.1-signed.tar gunzip krb5-1.6.1.tar.gz tar xvf krb5-1.6.1.tar ./configure make su: make install

IMAP server $ $ $ $

wget ftp://ftp.cac.washington.edu/imap/old/imap-2006e.tar.Z zcat imap.tar.Z | tar xvf ln -s /usr/local/ssl/lib/libcrypto.a /usr/lib/libcrypto.a make slx

$ vim ~/.bashrc export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib $ yum install xinetd.i386

51

Postfix $ yum remove sendmail $ yum install postfix $ $ $ $

ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-6.6.tar.gz ./configure make su: make install

stáhnout maildrop z: http://sourceforge.net/project/downloading.php?group id=5404& use mirror=kent&filename=maildrop-2.0.3.tar.bz2 (verze 2.0.4 neˇsla nainstalovat) $ ./configure $ make $ su: make install

Pine - emailov´ y klient $ $ $ $

wget ftp://ftp.cac.washington.edu/pine/pine.tar.gz gunzip pine.tar.gz tar xvf pine.tar cd pine4.64

Pˇred kompilac´ı pine je nutné udˇelat pár zmˇen v adresáˇri se zdrojov´ ymi kódy aplikace pine Vytvoˇren´ı symbolického linku na zdrojové soubory Kerbera $ ln -s /CESTA_K_SYSTEMU_KERBEROS/krb5-1.6.1/src krb5 Zkop´ırován´ı p˚ uvodn´ıch certifikát˚ u openssl ze zdrojov´ ych kód˚ u do adresáˇre s certifik´ aty operaˇcn´ıho systému $su: cp -R /CESTA_KE_ZDROJOV´ YM_K´ OD˚ UM_OPENSSL/certs/* /usr/local/ssl/certs Kompilace aplikace ./build slx

/home/user/.bashrc: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib

52

Dodatek B

Konfigurace postfix, imap, Kerberos, pine Kerberos ´ Uprava konfiguraˇcn´ıch soubor˚ u $ vim /etc/krb5.conf [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = REALM [realms] REALM = { kdc = domena.cz:88

- mus´ı b´ yt jméno, které NEUKAZUJE na 127.0.0.1 nebo “localhost” (funguje napˇr. 192.168.2.5) admin_server = domena.cz:750 database_name = /usr/local/var/krb5kdc/principal admin_keytab = FILE:/usr/local/var/krb5kdc/kadm5.keytab acl_file = /usr/local/var/krb5kdc/kadm5.acl key_stash_file = /usr/local/var/krb5kdc/.k5.REALM kdc_ports = 750,88

} [domain_realm] - pˇrevádˇen´ı doménov´ ych jmen na realmy, pokud nejsou explicitnˇe zadané .domena.cz = REALM domena.cz = REALM .localhost = REALM localhost = REALM 53

[kdcdefaults] acl_file = /usr/local/var/krb5kdc/kadm5.acl admin_keytab = /usr/local/var/krb5kdc/kadm5.keytab v4_mode = nopreauth Vytvoˇren´ı soubor˚ u, ve kter´ ych budou uloˇzeny zaˇsifrované kl´ıˇce a tikety. Nastaven´ı uˇzivatel˚ u, kteˇr´ı budou m´ıt pˇr´ıstup k administrátorsk´ ym funkc´ım systému Kerberos. $ touch /usr/local/var/krb5kdc/kadm5.keytab $ touch /usr/local/var/krb5kdc/kadm5.acl Vytvoˇren´ı databáze Kerbera $ /usr/local/sbin/kdb5_util -s create (Zruˇsen´ı databáze se provede pˇr´ıkazem) ($ /usr/local/sbin/kdb5_util destroy) Spuˇstˇen´ı serveru Kerbera $ /usr/local/sbin/krb5kdc Pˇridán´ı uˇzivatele do systému Kerberos $ /usr/local/sbin/kadmin.local > addprinc username Pˇridán´ı sluˇzby do systému Kerberos $ /usr/local/sbin/kadmin.local > addprinc -randkey imap > ktadd imap Pˇrihláˇsen´ı uˇzivatele $ kinit username Postfix - poˇ stovn´ı server ´ Uprava hostname a domainname systému: $ vim /etc/hosts 192.168.2.5 username domena.cz $ domainname domena.cz $ hostname username Konfigurace postfixu: $ vim /etc/postfix/master.cf - doruˇcován´ı a filtrován´ı poˇsty maildrop unix n n pipe flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient} $ /etc/postfix/main.cf: mail_owner = postfix 54

myhostname = domena.cz inet_interfaces = localhost #mailbox_command = maildrop - mus´ı b´ yt zakomentované virtual_transport = maildrop maildrop_destination_recipient_limit = 1 Nastaven´ı alias˚ u (uˇzivatel, kter´ y má dostávat emaily urˇcené pro uˇzivatele root) $ vim /etc/aliases root: username $ newaliases Po zmˇenˇe konfigurace restart sluˇzby $ /sbin/service postfix restart

Imap server Imap server neobsahuje ˇzádné konfiguraˇcn´ı soubory. Jeho nastaven´ı se provád´ı pouze pomoc´ı parametr˚ u pˇri kompilaci. Pˇred samotnou kompilac´ı bylo nutné provést následuj´ıc´ı zmˇeny. $ vim ./Makefile EXTRAAUTHENTICATORS=gss PASSWDTYPE=gss lfd: SPECIALS=‘‘SSLINCLUDE=/usr/local/ssl/include SSLLIB=/usr/local/ssl/lib ...’’

$ vim ./src/osdep/unix/Makefile SSLINCLUDE=$(SSLDIR)/include $ vim ./src/osdep/unix/Makefile.gss GSSINCLUDE=/usr/local/include/gssapi $ ln -s /usr/local/ssl/lib/libcrypto.a /usr/lib/libcrypto.a Pˇri pˇrekladu bylo nutné zapnout podporu pro IPv6, jinak se pˇreklad nezdaˇril $ make lfd (ipv6 support: YES) Bylo nutné nastavit promˇennou prostˇred´ı LD_LIBRARY_PATH $ vim ~/.bashrc export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib

55

Po u ´spˇeˇsné kompilaci serveru zb´ yvá nastavit xinetd démona, kter´ y bude spouˇstˇet imap server. Je nutné proto vytvoˇrit soubory /etc/xined.d/imap a /etc/xined.d/imaps, které budou m´ıt následuj´ıc´ı obsah. $ vim /etc/xined.d/imap(s) service imap(s) { socket_type = stream wait = no user = root server = /cesta_k_souboru_imapd log_on_success += HOST DURATION log_on_failure += HOST disable = no }

(/usr/sbin/imapd)

Konfigurace xinetd démona a imap serveru je u konce, zb´ yvá jen restartovat xinetd démona $ /sbin/service xinetd restart

Pine - emailov´ y klient U emailového klienta pine nebylo tˇreba dˇela ˇzádné zmˇeny v konfiguraci.

56

Dodatek C

GSSAPI Autentizace pine:

auth_gssapi_valid gss_import_name // name = unknown@REALM gss_release_name

imap:

auth_gssapi_valid gss_import_name // name = imap@REALM gss_release_name

imap:

auth_gssapi_server gss_import_name // name = imap@REALM gss_acquire_cred

pine:

auth_gssapi_client gss_import_name // name = imap@REALM gss_init_sec_context

imap:

gss_accept_sec_context

pine:

gss_release_buffer gss_init_sec_context

imap:

gss_release_buffer gss_display_name gss_wrap gss_seal

pine:

gss_unwrap gss_unseal

57

gss_release_buffer gss_wrap gss_seal gss_release_buffer gss_delete_sec_context gss_release_name imap:

gss_release_buffer gss_unwrap gss_unseal gss_release_buffer gss_release_buffer gss_release_name gss_delete_sec_context gss_release_cred gss_release_buffer gss_release_name

58

AUTENTIZACE A AUTORIZACE UŽIVATELE

Recommend Documents