Aplikace univerzálního rámce řízení přístupu

2012/37 – 11. 6. 2012

Aplikace univerzálního rámce řízení přístupu Karel Burda, Petr Ležák Fakulta elektrotechniky a komunikačních technologií VUT v Brně Email: [email protected], [email protected]

Abstrakt – Současné systémy řízení přístupu v počítačových sítích (např. RADIUS, IEEE 802.1X) jsou velmi různorodé, úzce specializované a neschopné vzájemné spolupráce. Možným řešením těchto problémů je univerzální rámec řízení přístupu, který je založen na myšlence, že všechna zařízení počítačové sítě jsou vybavena tzv. portály řízení přístupu. Každý takový portál řídí přístup jiných zařízení k aktivům daného zařízení nebo vyjednává přístup aplikací z daného zařízení k aktivům jiných zařízení. Ke komunikaci mezi portály byl navržen dvoustranný protokol ACP. Zprávy tohoto protokolu umožňují sjednání požadovaných aktiv, sjednání metody autentizace, uskutečnění autentizace, schválení přístupu a účtování přístupů. Kombinace určitým způsobem řetězených nebo vložených transakcí protokolu ACP umožňují realizovat libovolně složitá schémata řízení přístupu. Cílem tohoto článku je prezentovat možnosti univerzálního rámce řízení přístupu na několika aplikacích.

2 Protokol ACP Protokol ACP (Access Control Protocol) je univerzální dvoustranný protokol určený pro řízení přístupu k aktivům. Strana, která požaduje přístup k aktivům, se nazývá Žadatel a strana, která tato aktiva poskytuje se nazývá Poskytovatel. Jeden kompletní běh protokolu ACP, tj. postupnost zpráv mezi Žadatelem a Poskytovatelem, která souvisí s řízením přístupu k požadovaným aktivům, se nazývá transakce. Formát zpráv protokolu ACP je uveden na obr. 1 Code

Length

AVP1

...

AVPn

Obr. 1: Formát zpráv protokolu ACP. Záhlaví zprávy protokolu ACP sestává z následujících polí:  Code (1 oktet): Toto pole určuje typ zprávy (viz dále).  Identifier (3 oktety): Toto pole identifikuje konkrétní transakci v daném spoji.  Length (3 oktety): Toto pole udává celkovou délku zprávy v oktetech.

1 Úvod Současné systémy řízení přístupu v počítačových sítích (např. systémy podle standardu RADIUS, IEEE 802.1X, Kerberos, OpenID atd.) jsou velmi různorodé. Specializují se na jediný scénář přístupu a ke komunikaci využívají jediný přenosový protokol. Důsledkem uvedených okolností je skutečnost, že nejsou schopny vzájemné spolupráce. Možným řešením uvedených problémů je univerzální rámec řízení přístupu [1], který je založen na myšlence, že všechna zařízení počítačové sítě jsou vybavena tzv. portály řízení přístupu. Portál řízení přístupu je součást operačního systému, která řídí přístup jiných zařízení k aktivům daného zařízení nebo vyjednává přístup aplikací z daného zařízení k aktivům jiných zařízení. Ke komunikaci mezi portály byl navržen dvoustranný protokol ACP [2]. Zprávy tohoto protokolu umožňují sjednání požadovaných aktiv, sjednání metody autentizace, uskutečnění autentizace, schválení přístupu a účtování přístupů. Kombinace určitým způsobem řetězených nebo vložených transakcí protokolu ACP umožňují realizovat libovolně složitá schémata řízení přístupu. Cílem tohoto článku je prezentovat výzkumníkům a vývojovým specialistům možnosti zmiňovaného rámce řízení přístupu. V následujících kapitolách je stručně popsán protokol ACP a dvě možné aplikace univerzálního rámce řízení přístupu. První aplikací je řízení přístupu osob z cizích organizací do prostorů tzv. domácí organizace a druhou aplikací je elektronický platební systém pro drobné nákupy. V závěru článku je uvedeno stručné shrnutí univerzálního rámce řízení přístupu a jsou zhodnoceny jeho možnosti.

Identifier

Zbytek zprávy sestává z n bloků AVP (Attribute-Value Pair), kde n = 0, 1, 2, .... Formát bloku AVP uvádí obr. 2. Type

Length

Value

Obr. 2: Formát bloku AVP. Blok AVP sestává z následujících polí:  Type (1 oktet): Toto pole určuje typ AVP, tj. atribut (např. výsledek autentizace, zpráva EAP atd.).  Length (1 nebo 2 oktety): Toto pole určuje délku pole Value v oktetech.  Value (maximálně 216-1 oktetů): Toto pole obsahuje hodnotu atributu. Kapacita tohoto pole postačuje pro přenos celých zpráv EAP, kryptografických certifikátů, fotografií osob atd. V návrhu internetového standardu [2] je definována řada různých typů AVP. Jedná se o jména entit, adres zařízení, kódy metod, kódy aktiv, kryptografická primitiva apod. Lze tak jimi vytvářet široké spektrum variant řízení přístupu. Navíc je návrh standardu otevřený a tak je možné definovat další typy AVP podle potřeb konkrétní aplikace.

37 – 1

V protokolu ACP je definováno šest typů zpráv:

2012/37 – 11. 6. 2012

 Start. Tato zpráva zahajuje novou transakci. Odesílatelem této zprávy je vždy Žadatel. Zpráva Start může obsahovat kód požadovaného aktiva (pokud Žadatel tento kód zná) i typ autentizace (pokud Žadatel zná typ autentizace, kterou Poskytovatel pro dané aktivum vyžaduje).  Finish. Tato zpráva ukončuje transakci a odesílatelem této zprávy je vždy Poskytovatel. Zpráva Finish obsahuje oznámení pro Žadatele, případné další údaje nebo samotné aktivum (např. digitálně podepsaný výsledek autentizace).  Offer. Tato zpráva je vždy odesílána Poskytovatelem a obsahuje nabídku dostupných aktiv nebo nabídku autentizací, které jsou pro dané aktivum Poskytovatelem požadovány.  Specification. Tato zpráva je vždy odesílána Žadatelem jako reakce na zprávu Offer. Zpráva obsahuje Žadatelovu volbu z nabízených aktiv nebo autentizačních metod.  Request. Tyto zprávy jsou odesílány Poskytovatelem a jsou užity k autentizaci. Autentizaci začíná vždy Poskytovatel.  Response. Tyto zprávy jsou odesílány Žadatelem a jsou užity k autentizaci. Elementární transakci protokolu ACP ilustruje Tab. 1. V prvním sloupci tabulky jsou uvedeny zprávy, které odesílá Žadatel. Druhý sloupec tabulky uvádí zprávy odeslané Poskytovatelem a třetí sloupec je věnován poznámkám. Každý řádek tabulky reprezentuje jeden krok protokolu ACP. Tab. 1: Schéma elementární transakce protokolu ACP. Žadatel

Poskytovatel

Start → ← Offer Specification →

← Offer Specification → ← Request Response → ← Finish

Poznámky Zahájení transakce. Zahajuje vždy Žadatel. Sjednání požadovaného aktiva. Pokud Žadatel požadované aktivum uvede ve zprávě Start nebo existuje jediná možnost, tak může být vynecháno. Sjednání typu autentizace. Pokud Žadatel příslušný typ autentizace uvede ve zprávě Start, tak může být vynecháno. Výměna autentizačních zpráv. Podle typu autentizace může být dvojic Request - Response více. Oznámení Poskytovatele o schválení přístupu a o ukončení transakce.

provedenou v rámci vybudování bezpečného kanálu. V takovém případě lze transakci ACP redukovat pouze na výměnu zpráv Start a Finish. Takto redukovanou transakci protokolu lze například použit ke komunikaci mezi jednotlivými prvky systému řízení přístupu. Stejný přístup lze využít i pro účtování. Na jedné transakci se podílejí vždy pouze dva portály (tj. dvě zařízení), avšak na řízení přístupu se mohou podílet i další zařízení. Pro zahrnutí více zařízení existují dvě možnosti. První možností je sekvenční zřetězení více transakcí. V takovém případě Žadatel v transakci získá nějaká aktiva (např. podepsaný výsledek autentizace) a tato aktiva použije v následující transakci. Druhou možností jak do řízení přístupu zahrnout více zařízení je vložení nové transakce do již probíhající transakce.V tomto případě musí být k ukončení nějaké dřívější transakce nejprve uskutečněna nová transakce. Příkladem je situace, kdy Poskytovatel otevře novou transakci k externímu autentizátoru, aby autentizoval Žadatele (viz obr. 3). Na tomto obrázku je Žadatelem Uzel1 a Poskytovatelem je Uzel2. Uzel1 pošle Uzlu2 zprávu Start1. Tato zpráva zahájí Transakci1. Zpráva Start1 obsahuje požadované aktivum a příslušný typ autentizace a proto se výměna zpráv Offer a Specification neuskuteční. Nyní musí být autentizován Uzel1, avšak Uzel2 nezná verifikační faktor Uzlu1 a proto tuto autentizaci nemůže provést. Z tohoto důvodu Uzel2 vybuduje bezpečný kanál TLS k příslušnému autentizátoru, kterým je v tomto případě Uzel 3. V průběhu budování kanálu TLS se Uzel2 a Uzel3 navzájem autentizují. Uzel2 zahájí ve vybudovaném kanálu TLS vůči Uzlu3 Transakci2. Požadovaným aktivem této transakce je provedení autentizace Uzlu1, Žadatelem je Uzel2 a Poskytovatelem je Uzel3. Zpráva Start2 rovněž obsahuje požadované aktivum a příslušný typ autentizace a proto se výměna zpráv Offer a Specification neuskuteční. Uzel3 proto hned zahájí autentizaci vysláním zprávy Request2. Uzel2 vyjme příslušná AVP z této zprávy a odešle je ve zprávě Request1, která je zprávou Transakce1. Uzel1 vypočítá autentizační odpověď a tuto odpověď odešle do Uzlu2 ve zprávě Response1. Uzel2 z této zprávy vyjme příslušná AVP a odešle je ve zprávě Response2, která je zprávou Transakce2. Uzel3 provede autentizační výpočty a výsledek autentizace zašle ve zprávě Finish2. Tato zpráva současně ukončuje Transakci2. Uzel2 na základě výsledku autentizace rozhodne o přístupu k požadovanému aktivu a toto rozhodnutí je zasláno Uzlu1 ve zprávě Finish1.

Transakce protokolu ACP mohou být redukovány. Výměna dvojic zpráv Offer-Specification není nutná, pokud Žadatel požadované aktivum i příslušnou autentizační metodu uvede ve zprávě Start. Lze rovněž vypustit výměnu zpráv Request Response pokud Žadatel i Poskytovatel jsou koncovými uzly bezpečného kanálu (např. kanálu TLS [3]). Důvodem je skutečnost, že autentičnost protější strany je zaručena autentizací

37 – 2

Uzel1

Uzel2 Start1 Request1 Response1 Finish1

1. transakce

Uzel3 Start2 Request2 Response2 Finish2

2. transakce

Obr. 3: Princip vložení transakce.

2012/37 – 11. 6. 2012

3 Řízení přístupu osob Prvním příkladem využití univerzálního rámce řízení přístupu je systém řízení přístupu osob do areálů nebo budov. Stávající systémy umožňují řídit přístup osob patřících do dané organizace [4]. Tato tzv. domácí organizace v praxi spolupracuje s řadou dalších organizací (tzv. cizí organizace) a přitom se často požaduje, aby pracovníci cizích organizací měli přístup do vybraných prostorů domácí organizace (úklid, pravidelný servis apod.). Soudobé přístupové systémy však s přístupovými systémy jiných organizací nedokáží spolupracovat. Proto je nutné přístup osob z cizích organizací řešit jiným způsobem. Nejčastěji jejich autentizací provádí ostraha domácí organizace nebo jsou jim dočasně vydány autentizační předměty (např. přístupové karty). Uvedená řešení jsou však rigidní a obsahují bezpečnostní rizika. Navrhovaný systém je postaven na spolupráci přístupových systémů domácí i cizí organizace. Základní strukturu navrženého řešení ilustruje obr. 4.

Obr. 4: Systém řízení přístupu do domácí organizace. Osoba X cizí organizace je vybavena bezkontaktní autentizační kartou Z. U vstupu do prostor domácí organizace se nachází dveřní terminál A, který je vybaven čtečkou autentizačních karet a zároveň je připojen prostřednictvím lokální sítě LAN k přístupovému serveru B domácí organizace. Tento server má přístup na Internet a může proto komunikovat s přístupovým serverem Y cizí organizace. Autentizační karta Z, dveřní terminál A a také oba přístupové servery B i Y obsahují portál. Zprávy protokolu ACP mezi kartou Z a terminálem A se přenášejí bezdrátovým kanálem podle standardu ISO 14443. Zprávy mezi A - B a mezi B - Y se přenášejí v kanálu TLS. Kanál TLS mezi A a B je trvalý. Kanál TLS mezi B a Y může být podle frekvence přístupů buď trvalý nebo dočasný. Dočasný kanál se buduje pro každý jednotlivý přístup. Zprávy protokolu ACP přenášené v kanálech TLS jsou považovány za autentické, protože v rámci budování kanálu TLS došlo k ověření identity protistrany. Předpokládejme, že bezpečnostní správci obou organizací se dohodli na autentizační metodě typu výzva-odpověď. Bezpečnostní správce cizí organizace vydal osobě X ze své organizace autentizační kartu Z, která obsahuje identifikátor karty X@Y a tajný klíč KX. Stejné údaje jsou uloženy rovněž v serveru Y. Princip navrhovaného řešení systému řízení přístupu spočívá v tom, že autentizaci osob z domácí organizace provádí server B a autentizaci osob z cizí organizace provádí server Y. Komunikaci související s řízením přístupu osoby z cizí organizace ilustruje obr. 5.

Obr. 5: Komunikace k řízení přístupu do domácí organizace. První transakce probíhá mezi kartou Z a terminálem A. Aby držitel karty nemusel svoji kartu držet u čtečky po celou dobu řízení přístupu, tak účelem této transakce je získat údaje pro následnou autentizaci, kterou provede buď server B nebo Y. Ve zprávě Start1 uvede karta svůj identifikátor X@Y (AVP typu NAME_SUP_G). Protože aktivum je v tomto případě jediné (otevření dveří) a autentizační metoda je předem dána, tak jsou vynechány výměny zpráv typu Offer – Specification. Terminál proto v reakci na zprávu Start1 vyšle zprávu Request1, kde je uvedena náhodná výzva R (AVP typu INIT). Karta pomocí tajného klíče KX vypočítá odpověď W = f(R, KX ) a odešle ji ve zprávě typu Response1 (AVP typu HMAC). Terminál popsanou transakci uzavře zprávou Finish1. Druhá transakce proběhne mezi terminálem A a serverem domácí organizace B. Terminál ve zprávě Start2 vyšle informace potřebné pro autentizaci držitele karty. Zpráva bude obsahovat identifikátor terminálu (AVP typu NAME_SUP_L), kód aktiva, kterým je žádost o autentizaci (AVP typu ASSET_G), identifikátor autentizovaného, kterým je řetězec X@Y (AVP typu NAME_ENT_G), výzvu R (INIT) a odpověď na výzvu W (HMAC). Server z identifikátoru autentizovaného zjistí, že držitel karty náleží do cizí organizace a proto zahájí třetí transakci k serveru Y. Zpráva Start3 bude obsahovat identifikátor domácího autentizačního serveru (AVP typu NAME_SUP_G), kód aktiva, kterým je žádost o autentizaci (AVP typu ASSET_G), identifikátor autentizovaného, kterým je řetězec X@Y (AVP typu NAME_ENT_G), výzvu R (INIT) a odpověď na výzvu W (HMAC). Portál serveru Y provede vlastní výpočet odpovědi W´ a porovná ji s přijatou odpovědí. Pokud W = W´, tak autentizovaná osoba disponuje autentizační kartou s klíčem KX, tj. jedná se o kartu osoby X. Ve zprávě Finish3 server Y uvede výsledek autentizace (AVP typu RESULT) a tím je třetí transakce ukončena. Server B na základě výsledku autentizace rozhodne o tom, zda zůstanou dveře zavřené, či se mají otevřít. Toto rozhodnutí (AVP typu RESULT) je předáno terminálu A ve zprávě Finish2, kterou je zároveň ukončena i druhá transakce. Jak již bylo uvedeno, výhodou popsaného řešení je možnost spolupráce přístupových systémů různých organizací. Využívá se přitom výhoda jednotného protokolu pro výměnu zpráv souvisejících s řízením přístupu.

37 – 3

2012/37 – 11. 6. 2012

4 Drobné elektronické platby Dalším příkladem možností univerzálního rámce řízení přístupu je systém drobných elektronických plateb. Tento systém by měl uživatelům umožnit provádět drobné on-line platby, jako je například koupě elektronické jízdenky městské hromadné dopravy, koupě vstupenky do muzea, platba za parkování apod. V navrhovaném systému jsou do sítě připojeny portály bank a zainteresovaných prodejců. Uživatelé jsou vybaveni vhodnými komunikačními zařízeními (např. chytrý telefon, iPad apod.). Tato komunikační zařízení (dále komunikátory) disponují vlastním portálem. Uživatel dostane při založení svého účtu u banky dva tajné klíče. Klíč KE je určen k šifrování zpráv mezi portálem banky (B) a portálem komunikátoru (K) a klíč KA je určen k autentizaci zpráv vyměňovaných mezi B a K. V navrhovaném systému dále předpokládáme komunikační systém podle obr. 6. V tomto systému portály bank B a portály prodejců P komunikují přes počítačovou síť prostřednictvím dočasných nebo trvalých spojů typu TLS. Jejich vzájemná komunikace je tímto způsobem utajená a autentizovaná. Komunikace mezi portály komunikátorů K a portály bank B je zajištěna stejnou počítačovou sítí, do které mají komunikátory přístup prostřednictvím přístupových bodů AP. Bezdrátové spojení mezi komunikátorem a AP může být řešeno podle standardu IEEE 802.11. Přístupové body v tomto případě nemusí zajišťovat utajení ani autentičnost přenášených dat. Komunikátorům je dovolena pouze komunikace s portály bank a jen pomocí protokolu ACP. Tím je zajištěno, že platební komunikační systém nebude zneužíván uživateli pro účely surfování apod.

Obr. 6: Komunikační systém pro drobné elektronické platby. Nyní si popíšeme možné řešení komunikace. Předpokládejme, že uživatel si chce zakoupit elektronickou jízdenku do prostředku místní hromadné dopravy (MHD). Prodejcem P tedy bude portál serveru příslušného podniku MHD. Uživatel si prostřednictvím svého komunikátoru vybere jeden z dosažitelných přístupových bodů. S ním zahájí komunikaci ilustrovanou na obr. 7. Protože portál AP funguje v navrhovaném řešení pouze jako tranzitní uzel, tak na obrázku uveden není. Ve zprávě Start1 komunikátor uvádí AVP, ze kterých lze zjistit identifikátor banky B (AVP typu NAME_PRO_G) a identifikátor komunikátoru K (AVP typu NAME_SUP_L). Portál AP si ověří, že se jedná o zprávu protokolu ACP. Pokud je identifikátor banky na seznamu povolených příjemců, tak zprávu Start1 této bance odešle. Portál banky ze zprávy Start 1 zjistí, že s ním byla zahájena nová transakce. Podle identifikátoru K zjistí potřebné klíče KE a KA. Portál B zašle zpět zprávu Offer1,1, ve které nabízí dostupná aktiva (AVP typu ASSET_L_TX). Mimo jiné je zde uvedena možnost

koupě jízdenky MHD. Uživateli se na obrazovce jeho komunikátoru objeví nabízená aktiva. Vybere si aktivum koupě jízdenky MHD a portál K zašle do B zprávu Specification1,1, ve které je toto aktivum uvedeno (AVP typu ASSET_L). Portál B vyšle další zprávu Offer1,2, ve které nabízí jednotlivé typy jízdenek podle ceny (opět AVP typu ASSET_L_TX). Uživateli se na obrazovce komunikátoru objeví nabídka jízdenek podle ceny. Dejme tomu, že si vybere jízdenku MHD v ceně X Kč. Tuto informaci portál K zašle do B ve zprávě Specification1,2 (opět AVP typu ASSET_L). Tím proběhlo sjednání aktiva.

Obr. 7: Komunikace k nákupu elektronické jízdenky. Nyní je zapotřebí uskutečnit autentizaci komunikátoru. Předpokládejme, že v popisovaném případě je v portálech přednastaven jediný typ autentizace a tak je sjednání typu autentizace vynecháno a přikročí se okamžitě k autentizaci. Portál B odešle zprávu Request1, která pro kontrolu obsahuje vybrané aktivum (ASSET_L_TX) a náhodné číslo (AVP typu INIT). Zřetězení kódu aktiva a náhodného čísla nazveme výzva R. Uživatel zkontroluje, zda se skutečně jedná o požadované aktivum a vydá příkaz k prokázání identity. Komunikátor zašle ve zprávě Response1 odpověď W = f(R, KA), což je autentizační kód (AVP typu HMAC), který přísluší výzvě R. Portál B provede vlastní výpočet odpovědi W´ a porovná ji s přijatou odpovědí. Pokud W = W´, tak komunikátor zná autentizační klíč KA majitele příslušného bankovního účtu. Tím byla provedena autentizace uživatele a zároveň ověřena i jeho volba. Portál B nyní zahájí transakci s portálem P, jejímž cílem je koupě jízdenky MHD v ceně X Kč. Předpokládáme, že mezi P a B existuje kanál TLS, takže spojení mezi touto dvojicí je utajené a autentizované. Portál B zašle do P zprávu Start 2, kterou zahajuje novou transakci. V této zprávě žádá o zaslání požadované jízdenky (ASSET_L). Portál P ve zprávě Finish2 tuto jízdenku zašle (AVP typu PROVE). Tím tato transakce mezi B a P končí. Provozovatel portálu P důvěřuje provozovateli portálu B a proto předpokládá, že cena jízdenky (X Kč) bude v nejbližším zúčtovacím termínu bankou převedena z účtu uživatele na jeho účet. Portál B jízdenku zašifruje klíčem KE a ve zprávě Finish1 (AVP typu ENC) ji odešle portálu K. Tím je zároveň ukončena také první transakce. Komunikátor jízdenku klíčem KE dešifruje a uživatel se jí bude moci v dopravním prostředku prokázat.

37 – 4

2012/37 – 11. 6. 2012

Popsanou komunikaci lze zjednodušit tak, že pokud si komunikátor z předchozích transakcí bude ukládat kódy aktiv, tak uživatel si bude moci aktivum vybrat ještě před zahájením transakce. Zpráva Start1 bude ještě navíc obsahovat kód vybraného aktiva a obě výměny zpráv Offer - Specification bude možné vynechat. Popsané řešení je jedno z mnoha. Samozřejmě existují další varianty řešení, kdy mohou být použity jiné autentizační metody a jiné kryptografické metody. Mohou být rovněž použity i jiné scénáře. Ve všech těchto případech však pokaždé vystačíme s konceptem portálů, které navzájem komunikují prostřednictvím zpráv protokolu ACP. Oproti stávajícímu řešení SMS jízdenek je navržené řešení poněkud složitější, avšak na druhou stranu je univerzálnější. Stávající systémy SMS jízdenek nedovolují interaktivní volbu aktiv a k autentizaci lze používat pouze metodu, která je v mobilních telefonech standardizovaná. Výše popsané řešení dovoluje interaktivní volbu aktiv a také volbu typu autentizační metody. Provozovatelé systému drobných plateb tak nejsou omezeni na nějaký konkrétní komunikační systém ani na autentizační metodu v něm implementovanou.

[4] Burda K., Strašil I.: Univerzální rámec pro přístupové systémy. In Bezpečnostní technologie, Systémy a Management 2011. Univerzita Tomáše Bati ve Zlíně, 2011. s. 1-4.

5 Závěr V článku je stručně popsán univerzální rámec pro řízení přístupu. Principem tohoto rámce je skutečnost, že každé síťové zařízení je vybaveno portálem, který řídí přístup k aktivům daného zařízení a současně vyjednává pro aplikace daného zařízení přístup k aktivům jiných zařízení. Výhodou tohoto řešení je skutečnost, že portály spolu komunikují jednotným protokolem ACP, který jim umožňuje sjednání požadovaných aktiv, sjednání metody autentizace, uskutečnění autentizace, schválení přístupu i účtování přístupů. Transakce protokolu ACP lze vzájemně vázat a vytvářet tak prakticky libovolně složitá schémata řízení přístupu. V článku byly prezentovány dva příklady využití univerzálního rámce řízení přístupu. První příklad ilustroval možnost spolupráce přístupových systémů do areálů různých organizací. Druhý příklad prezentoval možnosti sjednávání podmínek a parametrů přístupu spolu s možností aplikace obecného systému řízení přístupu jako platebního systému. Oba uvedené příklady ilustrovaly univerzalitu navrženého řešení a pestrou škálu jeho aplikací. Z tohoto důvodu se popsaný univerzální rámec řízení přístupu jeví slibným řešením pro budoucnost.

Literatura [1] Burda K.: Univerzální rámec pro řízení přístupu v počítačových sítích. Elektrorevue - Internetový časopis, roč. 2011, č. 9, s. 1-6. Dostupné online: . [2] Burda K., Strasil I., Pelka T., Stancik P.: Access Control Protocol (ACP). IETF, Fremont 2011. Dostupné online: . [3] Dierks T., Rescorla E.: The Transport Layer Security (TLS) Protocol. [RFC 5246]. IETF, Fremont 2008. Dostupné online: .

37 – 5