Autentizační protokoly v telekomunikačních a datových sítích Tomas Vanek
Autor: Tomas Vanek Název díla: Autentizační protokoly v telekomunikačních a datových sítích Zpracoval(a): České vysoké učení technické v Praze Fakulta elektrotechnická Kontaktní adresa: Technická 2, Praha 6
Inovace předmětů a studijních materiálů pro e-learningovou výuku v prezenční a kombinované formě studia
Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti
VYSVĚTLIVKY
Definice
Zajímavost
Poznámka
Příklad
Shrnutí
Výhody
Nevýhody
ANOTACE Tento modul poskytuje přehled autentizačních protokolů používaných v datových sítích. Popsány jsou protokoly PAP, CHAP, Kerberos, TACACS+, RADIUS, DIAMETER a také nejdůležitější metody protokolu EAP.
CÍLE Student získá přehled v oblasti autentizace. Bude chápat rozdíly mezi používanými autentizačními protokoly a schopen posoudit vhodnost jejich nasazení dle konkrétních potřeb.
LITERATURA [1]
Smith, Richard E. Authentication: From Passwords to Public Keys,:Addison Wesley, 2005, 550 str., ISBN: 978-0-201-61599-1
[2]
Nakhjiri Madjid, Nakhjiri Mahsa. AAA and Network Security for Mobile Access; Radius, Diameter, EAP, PKI and IP mobility: WILEY, 2006, 280 str., ISBN 978-0-47001194-7
Obsah 1 Autentizace obecně ............................................................................................................... 6 1.1
Úvod ........................................................................................................................... 6
1.2
Co to je autentizace .................................................................................................... 7
2 Základní kritéria autentizace .............................................................................................. 9 2.1
Úvod ........................................................................................................................... 9
2.2
Biometrika obecně .................................................................................................... 10
2.3
Kdo entita je ............................................................................................................. 12
2.4
Co entita vlastní ........................................................................................................ 14
2.5
Co entita ví ............................................................................................................... 17
3 Autentizační protokoly ...................................................................................................... 19 3.1
Obecné přístupy ........................................................................................................ 19
3.2
PAP ........................................................................................................................... 20
3.3
CHAP ....................................................................................................................... 21
3.4
EAP .......................................................................................................................... 23
3.5
AAA protokoly obecně ............................................................................................ 32
3.6
TACASCS+ .............................................................................................................. 34
3.7
RADIUS a DIAMETER ........................................................................................... 35
3.8
KERBEROS ............................................................................................................. 36
3.9
Závěrečný test........................................................................................................... 40
1 Autentizace obecně 1.1 Úvod Autentizace je pojem, se kterým se oblasti informační bezpečnosti potkáváme poměrně často. Cílem autentizace je ověřit totožnost člověka, serveru či komunikující strany, která se autentizuje. Jde o podobnou činnost, jako když policie s využitím informací v občanském průkazu kontroluje totožnost člověka. V tomto modulu se jednak seznámíte se základními přístupy k autentizaci, s obecnými možnostmi jak řešit autentizaci v počítačových sítích a dále s vybranými autentizačními protokoly, které lze potkat v dnešních počítačových a telekomunikačních sítích. Nelekněte se, většina názvů autentizačních protokolů vznikla z počátečních písmem slov, která charakterizují jejich činnost, a proto se píší velkými písmeny jako například PAP,CHAP, EAP, RADIUS, TACACS, DIAMATER.
1.2 Co to je autentizace Pojem autentizace byl neformálně představcem již v úvodní kapitole. Přesněji lze autentizaci definovat takto: Autentizace je proces identifikace nebo verifikace nějaké entity. Výsledkem autentizace je informace systému o identitě autentizované entity. Slovo autentizace má svůj základ v německém slově Kromě českého autentizace se můžete take setkat s výrazem
authentisierung.
•
autentifikace, které má původ ve francouzském slově authentification, a
•
autentikace pocházejícím z anglického authentication (podobně jako např. komunikace)
Poslední tvar není příliš častý, nicméně všechny tři jsou přípustné a lze používat libovolný z nich. Pokud Vás původ tohoto slova zajímá více, navštivte odkaz http://interval.cz/clanky/hrichy-pro-sileneho-korektora-autentizace-autentikacenebo-autentifikace/ S pojmem autentizace se často plete pojem autorizace. Každé z těchto slov však označuje zcela jinou činnost. Autorizace je proces, který se odehrává až po autentizaci. V průběhu autorizace dochází k rozhodnutí, zda-li má mít entita povolen či nepovolen přístupu k aktivům systému. Příkladem ze světa počítačů může být například situace, kdy máte na počítači sdílenou složku. Pro přístup je složce musíte zadat uživatelské jméno a heslo. Autentizace v tomto případě spočívá v kontrole kombinace jméno-heslo. Skutečnost, jestli budete mít v dané složce právo pouze ke čtení souborů, nebo i k jejich zápisu, či dokonce mazání je již výsledkem autorizace. Pokud bychom chtěli klasifikovat autentizační metody, lze nají celou řadu parametrů, podle kterých můžeme jednotlivé metody a postupy porovnávat: Kdo je autentizován: •
obě komunikující strany – vzájemná autentizace
•
pouze jedna komunikující strana – jednostranná autentizace
Kdy autentizace probíhá: •
pouze na počátku komunikace – jednorázová autentizace
•
kdykoliv (i opakovaně) v průběhu komunikace – kontinuální autentizace
7
Jakým mechanismem autentizace začíná: •
autentizovaná strana sama aktivně zahájí autentizaci – autentizace bez výzvy
•
autentizující strana vyzve autentizovanou – autentizace na vyžádání
Kde se autentizace provádí: •
proces autentizace probíhá přímo mezi komunikujícími entitami – přímá autentizace
•
proces autentizace probíhá s využitím externího autentizačního serveru – nepřímá autentizace
8
2 Základní kritéria autentizace 2.1 Úvod Existují tři základní kritéria, podle kterých je možné autentizaci provádět. •
kdo jsou – identifikace podle globálně jednoznačných parametrů (biometrika – otisky prstů, dlaní, sítnice, DNA apod.)
•
co mají – identifikace podle vlastnictví určitých předmětů (klíč, magnetická/čipová karta, USB token apod.)
•
co znají – identifikace pomocí přístupových hesel, číselných kombinací, osobních identifikačních čísel – PIN apod.
9
2.2 Biometrika obecně Do prvního způsobu autentizace patří řada metod a postupů, které se souhrnně označují jako biometrické metody neboli zkráceně biometriky. Tento typ autetnizace je vhodný pro autentizaci živých bytostí, které se vyznačují individuálními biologickými charakteristikami, které lze sledovat. Naopak je zcela nevhodný pro autentizaci počítačů, či elektronických systémů. Asi rychle uznáte sami, že autentizovat počítač na základě jeho váhy, rozměrů, či barvy by asi nebylo úplně nejšťastnější. Biometrické metody autentizace lze definovat následovně: Jedná se o automatizované metody identifikace nebo verifikace osoby na základě měřitelných fyziologických nebo behaviorálních vlastností člověka. Výhodou tohoto přístupu je skutečnost, že identifikace lidí na základě jejich osobních charakteristik je: •
jedinečná
•
minimálně proměnná
•
nelze je zapomenout, odcizit nebo ztratit (tedy kromě neopatrné práce s motorovou pilou apod.)
Mějte na paměti, že •
biometriky se liší o různou mírou spolehlivosti o cenou o společenskou přijatelností
•
biometrická data nejsou nikdy 100% shodná
•
je nutné povolit určitou variabilitu mezi registračním vzorkem a později získanými biometrickými daty
Kvalitu biometrik lze charakterizovat pomocí dvou základních veličin: •
FRR (False Rejection Ratio) - četnost nesprávného odmítnutí autorizovaného subjektu
•
FAR (False Acceptance Ratio) - četnost nesprávných přijetí neautorizovaného subjektu
Jak je vidět z obrázku, nikdy nelze dosáhnout stavu, kdy jsou obě veličiny nulové, proto je při volbě konkrétní biometrické metody nutné dopředu vědět, jaké bezpečnostní nároky na zabezpečovaný systém klademe, a na jejich základě pak stanovit přijatelné limity FAR a FRR.
10
Charakteristiky biometrických metod
Kromě základních charakteristik FAR,FRR a EER existují i dvě doplňkové, které berou v potaz skutečnost, že vždy existuje skupina uživatelů, která nemůže být z principu autentizována: •
FTER (Fail To Enroll Ratio)
•
FTAR (Fail to Acquire Ratio)
FTER kvantifikuje situace, kdy uživateli nemůže být vzorek odebrán, proto, že nemá zdroj biometrických dat (např. v případě analýzy duhovky proto, že uživatel je slepý) FTAR kvantifikuje situace, kdy uživatel přestože má k dispozici zdroj biometrických dat, nemůže vzorek odevzdat (např. v případě snímání otisků prstů a uživatele na invalidním vozíku, nedosáhne na snímač).
11
2.3 Kdo entita je Biometrické techniky lze dále rozdělit na dvě skupiny: •
statické – zkoumají anatomické charakteristicky, které se v čase neměnní (nebo alespoň ne rychle) o otisk prstu o otisk sítnice o tvar duhovky o geometrie ruky
•
dynamické – též behaviorální charakteristiky, které vyžadují interakci účastníka o dynamika podpisu o analýza hlasu o analýza chůze
V praxi se používají převážně statické metody, z nichž nejrozšířenější je identifikace na základě otisků prstů následovaná analýzou geometrie ruky a analýzou duhovky.
12
Příklady biometrických metod
Naprostá většina biometrických autentizačních metod vyžaduje fyzickou přítomnost člověka, který se autentizuje u snímače snímajícího měřenou veličinu. Jediným způsobem, u kterého fyzický přítomnost není vyžadována je analýza hlasu.
13
2.4 Co entita vlastní Druhým typem autentizace je autentizace na základě vlastnictví určitého předmětu. Jedná se o velmi starý způsob autentizace. V minulosti se k autentizaci používaly např. voskové pečeti na dopisech (autentizačním zařízením byl v tomto případě pečetní prsten), specifickým způsobem roztržený pohled nebo bankovka…
Historické tokeny
Dnes byly tyto předměty nahrazeny kartami s čárovým či magnetickým proužkem, kontaktním či bezkontaktním čipem nebo speciální bezpečnostní tokeny (např. RSA SecurID).
Současné tokeny
14
Token je obecné označení pro předmět, který autentizuje svého vlastníka. Dobrý token musí být: •
unikátní
•
nepadělatelný
Základem tokenu je jednosměrná hashovací funkce (OWHF – One Way Hash Function), která je inicializována tajným klíčem, který je zadán při výrobě a je pro každý token unikátní a •
čítačen, nebo
•
vnitřními hodinami
V obou případech je součástí systému i autentizační server, který provádí vlastní ověření informací předených uživatelem z tokenu. V případě tokenu s čítačem, je token vybaven tlačítkem, po jehož stisknutí dojde k vygenerování kódu na základě aktuální hodnoty čítače a tajného klíče. Poté je čítač inkrementován. Na základě uživatelského jména odeslaného uživatelem v průběhu autentizace, zjistí autentizační server, jaký tajný klíč je v tokenu příslušného uživatele a jaká byla hodnota čítače při předchozí úspěšné autentizaci. Následně může provést analogický proces vygenerování nového kódu jako uživatel. Protože se v praxi může stát, že uživatel stiskne tlačítko na tokenu, ale autentizaci neprovede, používá se zde metoda okna, která zajistí, že může dojít k určité odchylce mezi hodnotou čítače v tokenu a na straně autentizačního serveru. V případě, kdy kód odeslaný z tokenu nesouhlasí s kódem, který vygeneroval server, server začne generovat další autentizační řetězce se zvyšující se hodnotou čítače až do max. hodnoty dané velikostí okna. V případě nalezení shody si autentizační server zapamatuje hodnotu čítače, čímž dojde k sesynchronizování serveru s tokenem. V případě, kdy by uživatel pouze generoval nové autentizační kódy a nepředával je autentizačnímu serveru dojde po určité době k tomu, že se čítač tokenu dostane mimo okno a autentizace již nebude nikdy možná.
Token s čítačem
15
V případě tokenu s vnitřními hodinami je synchronizace mezi zobrazenou informací a informací, kterou očekává server zajištěna stabilitou oscilátoru v tokenu. Tokeny založené na vnitřních hodinách nepotřebují žádná tlačítka, mají pouze displej, kde se v pravidelných intervalech objevují nové kódy. Po dobu životnosti tokenu (typicky dva roky) je garantována maximální odchylka hodin na straně tokenu a serveru.
Token s vnitřními hodinami
Autentizace pomocí tokenu je často spojena s autentizací pomocí hesla. V tom případě hovoříme o dvoufaktorové autentizaci (předmět + heslo). Dvoufaktorová resp. obecně vícefaktorová autentizace zvyšuje bezpečnost celého autentizačního řešení, protože potencionální útočník je nucen získat více informací (např. ukrást token a ještě odposlechnout heslo). Do této kategorie patří také v praxi poměrně rozšířená autentizace bankovních operací pomocí SMS zpráv. Zde se využívá jiného komunikačního kanálu (GSM síť) k doručení kódu prokazujícího vlastnictví předmětu (SIM karta s konkrétním telefonním číslem). Banky tento doplňkový způsob autentizace používají ze dvou důvodů: 1. V porovnání s čipovými kartami se jedná o velmi levné řešení 2. Z hlediska obsluhy jde o velmi jednoduché řešení, čímž je výrazně redukována potřeba uživatelské podpory.
16
2.5 Co entita ví Autentizace na základě znalosti tajné informace je nejrozšířenějším typem autentizace. Používá se všude tam, kde uživatel musí zadat tajné heslo nebo PIN.
Token s vnitřními hodinami
Dobré heslo musí splňovat dva základní požadavky: 1. Musí být dobře zapamatovatelné 2. Musí být těžko uhodnutelné. Tyto požadavky jsou na první pohled zcela protichůdné. Mezi další požadavky kladená na hesla patří: •
obsahuje malá písmena, velká písmena, číslice a jiné znaky – co největší abeceda znemožní útoky hrubou silou
•
má dostatečnou délku (minimálně 8 znaků) – dostatečná délka znemožní útok hrubou silou
•
nejde o obvyklé slovo nebo známou frázi – odolnost proti slovníkovým útokům
•
nelze jej odvodit ze znalosti osoby vlastníka – odolnost proti „social engineering“ praktikám
•
je často obměňované – pokud se hesla mění příliš často, může to být kontraproduktivní
•
není poznamenáno nikde v okolí místa zadávání – alespoň ne v otevřeném tvaru
V případě, kdy je nutné si pamatovat velké množství hesel je dobré využít specializované programy určené pro bezpečné uchovávání hesel. Hesla jsou uložena v zašifrované podobě a uživateli stačí si zapamatovat pouze přístupové heslo k programu. 17
Příkladem takového programu je např. KeePass Password Safe (http://www.keepass.info), který je jednak multiplatformní (Windows, Linux, Android, iPhone/iPad, Windows Phone…) a navíc i OpenSource, takže je k dispozici zdarma a každý se může analýzou zdrojových kódů přesvědčit, že neobsahuje žádná tajná vrátka.
18
3 Autentizační protokoly 3.1 Obecné přístupy V případě elektronické komunikace se obvykle autentizovaný uživatel nachází fyzicky jinde, než systém vůči kterému se autentizuje. Proto je nutné zajistit bezpečný přenos dat s autentizačními údaji od uživatele k autentizačnímu serveru. A to je právě práce autentizačních protokolů. Angličtina pro označení balíku dat obsahujícího autentizační údaje (jméno/heslo) používá slovo credentials.
19
3.2 PAP Protokol PAP (Password Authentication Protocol) patří k nejstarším autentizačním protokolům, se kterým se je možné se ještě dneska setkat. Je popsán v doporučení RFC 1334. Lze ho charakterizovat pojmy: •
jednosměrná autentizace
•
jednorázová autentizace
•
autentizace bez výzvy
•
přímá autentizace
Autentizaci iniciuje vždy klient, pouze na počátku spojení a v autentizační zprávě posílá jméno a heslo v otevřeném tvaru.
Autentizační protokol PAP
PAP přenáší uživatelské jméno i heslo v otevřeném tvaru. Jeho odchycení je tím pádem triviální. Pokud je to možné, tomuto protokolu se vyhněte.
20
3.3 CHAP Protokol CHAP (Challenge Handshake Authentication Protocol) již také patří také poměrně k starým autentizačním protokolům. Je popsán v doporučení RFC 1994, a dnes se nejčastěji setkáme s variantou označovanou jako MS-CHAPv2. Protokl CHAP lze charakterizovat pojmy: •
jednosměrná autentizace
•
kontinuální autentizace
•
autentizace na vyžádání
•
přímá autentizace
Autentizaci iniciuje vždy server a může probíhat nejenom na počátku spojení, ale také kdykoliv v jeho průběhu, opakovaně. V autentizační zprávě se neposílá heslo v otevřeném tvaru. Autentizace je zahájena výzvou serveru. Výzvu tvoří řetězec náhodných dat typické délky 128B. Řetězec musí být pro každou autentizaci originální a nepředvídatelný. Klient použije přijmutou výzvu a heslo jako vstup do hashovací funkce MD5. V odpovědi serveru pošle uživatelské jméno v otevřeném tvaru a hash z hesla a výzvy. Server, na kterém musí být uloženo heslo provede na základě informace o uživatelském jménu stejnou operaci a přijatý hash a vypočtený hash porovná. V případě rovnosti končí autentizace úspěchem.
Autentizační protokol CHAP
Z původního protokolu CHAP v průběhu času vzniklo několik modifikací. Dnes se nejčastěji setkáme s verzí MS-CHAPv2. MS-CHAPv1 •
RFC 2433
•
od Windows Vista již není podporován
•
jako hashovací algoritmus využívá DES
•
na straně serveru nemusí být heslo v otevřeném tvaru, ale jsou podporovány formáty NT-hash a LAN-Manager-hash
21
•
umožňuje uživateli změnit heslo uložené na serveru
MS-CHAPv2 •
RFC 2759
•
podpora od Windows 2000
•
umožňuje vzájemnou autentizaci komunikujících stran
•
využívá hashovací funkci SHA-1
•
podporuje změnu uživatelského hesla na straně serveru
22
3.4 EAP Protokol EAP (Extensible Authentication Protocol) představuje další vývojový krok v autentizačních protokolech. EAP byl původně vyvinut jako autentizační protokol pro PPP (Point-to-Point Protocol), ale dnes se s ním můžeme setkat spíše při autentizaci v datových sítích standardu IEEE 802.3, 802.11 nebo 802.16. jako součást autentizačního rámce IEEE 802.1x. Protokol EAP je standardizován v RFC 5247. Jeho velkou výhodou je to, že EAP představuje pouze obecný rámec pro autentizaci na principu klient-server, ale vlastní proces autentizace vlastně vůbec neřeší. To, jak konkrétně se bude autentizace provádět (jestli bude vzájemná, nebo jednostranná, jestli se k autentizaci použijí certifikáty X.509, nebo jméno/heslo…) je definováno až v jeho jednotlivých variantách – tzv. EAP-metoda. Ty jsou obvykle pojmenované ve tvaru EAP-něco , kde „něco“ popisuje konkrétní variantu protokolu EAP. Celkem existuje více než 40 EAP-metod. K nejznámějším patří: •
EAP-MD5
•
EAP-TLS
•
EAP-TTLS
•
EAP-FAST
•
EAP-PEAP
•
EAP-PKM
Tento způsob umožňuje jednoduše vytvářet nové autentizační mechanismy s využitím stejného autentizačního rámce EAP.
Struktura rámce EAP
Na obrázku je uvedena struktura rámce EAP. Pole kód určuje typ zprávy (viz tabulku), pole identifikátor zaručuje správné pořadí doručování, pole délka specifikuje délku datového pole a poslední pole EAP data obsahuje data EAPMetoda.
23
Přehled typů EAP zpráv
Typ zprávy
kód
Request Identity
1
Response
2
Success
3
4.1 EAP-Metoda Tento protokol, který je zapouzdřený v poli EAP data, popisuje konkrétní způsob dojednání autentizace (konkrétní autentizační metodu). Zároveň je tento protokol určen pro přenos autentizačních informací konkrétní metody, které jsou zapouzdřený v datovém poli rámce protokolu. Obecně jsou data, jež mohou být přenášena tímto protokolem, závislá na hodnotě datového pole typ v EAP rámci. Například není možné ve zprávě Response (kód 2) přenášet MD5-Challenge. Polem „Kód EAP-Metody“ v rámci EAP-Metoda je tak určen typ vlastní autentizační metody obsažené v datovém poli rámce EAP-Metoda, data EAPMetoda, nebo druh požadované zprávy sloužící pro vyjednání konkrétní autentizační metody.
Struktura rámce EAP-Metoda
Základních osm povinně podporovaných kódů specifikuje RFC 3478. Jedná se o kódy 1 − 6, 254 a 255. Význam některých kódů zpráv EAP-Metoda
Typ EAP-Metoda
kód
Identity
1
Notification
2
NAK
3
MD5-Challenge
4
One-Time Password
5
Generic Token Card
6
24
EAP-TLS
13
LEAP
17
EAP-TTLS
21
PEAP
25
EAP-MSCHAP-V2
29
Expanded NAK
254
Experimental
255
Nejčastěji používaný kód 1 je určen pro přenášení autentizačních údajů nesených ve zprávách EAP protokolu typu 1 a 2. Pro oznamování výstrah, jako je blížící se vypršení hesla nebo chyb slouží zpráva s číslem kódu 2. V případě odmítnutí navržené metody autentizačním serverem může být klientem zaslána zpráva s kódem 3 − Neakceptování nebo s kódem 254 − Expanded NAK. Zpráva NAK je považována za zastaralou a po jejím přijetí musí být autentizačním serverem poslána zpráva odmítající přístup do sítě. Ve zprávě Expanded NAK je odmítnuta nabízená autentizační metoda a jsou zde obsaženy klientem navržené metody, které jsou hierarchicky uspořádány. Tímto vylepšením je dosaženo zrychlení dohody ohledně autentizační metody. Přehled některých dalších kódů je uveden v tabulce. Mnoho dalších metod pro provádění autentizace již není doporučením vyžadováno. Každá metoda je však označena svým číslem, bez ohledu na to, zdali se jedná o veřejně popsanou metodu nebo chráněnou metodu výrobce. Mezi dva nejčastěji používané principy autentizace lze zařadit autentizace pomocí certifikátů a hesel nebo pomocí metod vytvářejících zabezpečený tunel, ve kterém je pak prováděna další metoda autentizace. Tento mechanismus umožňuje zapouzdřovat další EAP metody (ať již ty z předchozí tabulky nebo i zcela nové) do datového pole rámce EAP-Metoda. Tímto rozšířením je výrazně zvýšen počet možných metod pro autentizaci nad dvě stě padesát pět.
Rozšíření pole „Data EAP-Metody“ z rámce EAP-Metoda
Pokud je v poli kód výrobce obsažena hodnota 0, pak jsou v dalších polích pouze data vztahující se k jedné ze základních metod. V případě, že je v tomto poli obsažena jiná hodnota, pak jde o specifický kód výrobce, který mu byl přidělen organizací IANA, a význam dat v dalších polích nemusí být veřejně popsán. 25
4.2 Vybrané metody EAP V této kapitole budou probrány nejdůležitější metody protokolu EAP.
4.2.1
EAP-MD5
Jedná se o jednu z osmi základních EAP metod popsanou v RFC 3748. EAP-MD5 umožňuje pouze jednosměrnou autentizaci klienta založenou na mechanismu výzva-odpověď velmi podobnou protokolu MS-CHAPv2. Metoda EAP-MD5 neumožňuje bezpečnou výměnu klíčů, proto ji nelze použít v bezdrátových sítích a je vhodná maximálně v klasických LAN sítích s metalickým nebo optickým médiem. Jedná se o velmi slabý způsob autentizace náchylný na MITM (Man in the Middle) útok. Protože nedochází k autentizaci serveru, je zde možnost podvržení identity serveru tzv. spoofing. •
jednosměrná autentizace klienta
•
náchylnost na slovníkový útok
•
nelze vyžít k distribuci klíčů
4.2.2
EAP-TLS (Transport Layer Security)
EAP-TLS je jedna z nepovinných, ale formálně dokumentovaných metod s širokou podporou mezi výrobci zařízení. Poskytuje velkou míru zabezpečení komunikace mezi klientem a autentizačním serverem, která se vyznačuje obtížnější implementaci. Bezpečnost metody spočívá v protokolu TLS, který poskytuje možnost oboustranné autentizace, zajištění integrity přenášených dat, mechanismu pro vyjednání šifrovacího algoritmu a bezpečné výměny klíčů mezi klientem a autentizačním serverem využitím digitálních certifikátů X.509v3. Ještě vyšší míry zabezpečení lze dosáhnout uchováváním certifikátů na smart-kartách. EAP-TLS je popsán v RFC 5216. Základní nevýhodou EAP-TLS jsou její zvýšené nároky na implementaci, dané nutností využívat certifikáty. V případě použití jiných certifikátů než od veřejně uznávané certifikační autority je třeba, aby tyto certifikáty byly vygenerovány lokálně, což představuje požadavek na existenci certifikačního serveru. Obě varianty tedy představují další finanční zátěž při implementaci. Dalším nezanedbatelným faktem je rovněž potřeba většího počtu výměn zpráv mezi klientem a autentizačním serverem oproti jiným metodám, což způsobuje problémy pro aplikace pracující v reálném čase při přepojování mezi přístupovými body v bezdrátové síti (roaming). Přestože podpora EAP-TLS je mezi výrobci hardwaru (Cisco, 3Com/HP, Juniper, Foundry, … ) i softwaru (MS od Windows 2000 SP4 dál, MacOS od 10.3, iOS, Android, Linux,…) vysoká, v praxi se používá pouze zřídka.
26
•
vzájemná autentizace
•
klient i server používají certifikáty
•
nejbezpečnější EAP metoda
•
nejdražší a nejnáročnější na implementaci - vyžaduje PKI, proto se příliš nepoužívá
•
široká podpora v operačních systémech
•
používá se málo
4.2.3 EAP-LEAP (Lightweight Extensible Authentication Protocol [http://en.wikipedia.org/wiki/Lightweight_Extensible_Authenticat ion_Protocol] ) Tato metoda je určena k autentizaci v bezdrátových sítích IEEE 802.11. Byla vyvinuta firmou Cisco v době, kdy ještě nebyl publikován standard IEEE 802.11i. Jedná se o proprietární metodu, která používá dynamické WEP (nebo TKIP) klíče k autentizaci mezi klientem a autentizačním serverem. EAP-LEAP není nativně podporován v MS Windows, nicméně je podporován řadou bezdrátových adaptérů resp. jejich ovládacím softwarem. LEAP je založen na modifikovaném protokolu MS-CHAPv2. V dnešní době by se již neměl nepoužívat, protože byly objeveny bezpečnostní slabiny, které vedly k možnosti získat ze zachycených zpráv hesla (volně dostupný program ASLEAP). Cisco doporučuje nahradit LEAP protokoly EAP-FAST, EAP-PEAP nebo EAP-TLS. •
vzájemná autentizace klienta a serveru
•
proprietární protokol firmy Cisco
•
není bezpečný - jsou k dispozici nástroje pro získání hesel
4.2.4 EAP-FAST Tunneling)
(Flexible
Authentication
via
Secure
Metoda společnosti Cisco vytvářející zabezpečený tunel, kterým je prováděna výměna autentizačních informací pomocí další metody. Celkem má tato metoda tři fáze a průběh autentizace pomocí této metody je veřejně popsán. Tato metoda je uvažována jako nástupce metody LEAP, u které byly objeveny bezpečnostní slabiny. V první fázi autentizace je poskytnut oběma stranám tzv. předsdílený klíč, označovaný jako PAC. Tento klíč může být distribuován dynamicky nebo manuální konfigurací, která je doporučována pro eliminaci možnosti odposlechu a pozdějšího zneužití klíče. Tento klíč je poté použit při každém pokusu
27
o autentizaci klienta. V druhé fázi je pomocí PAC vytvořen TLS (Transport Layer Security) tunel a dohodnuty parametry TLS protokolu. Poté je v poslední fázi provedena autentizace klienta pomocí jména hesla přenášeného v šifrovaném tunelu. Tato metoda je výpočetně nenáročná (nevyžaduje digitální certifikáty a PKI)a určená pro bezdrátové sítě IEEE 802.11. •
vytvořený firmou Cisco jako náhradu LEAP
•
vzájemná autentizace
•
použití zabezpečeného tunelu (stejně jako EAP-TTLS nebo PEAP)
•
EAP-FAST nevyžaduje, aby se server autentizoval pomocí certifikátu
•
pro pomalé klienty typu WiFi telefony, kde by ověřování digitálních certifikátů trvalo dlouho
•
použití prakticky omezeno pouze na WiFi sítě se zařízeními (bezdrátové přístupové body - AP) od firmy Cisco
4.2.5
EAP-TTLS (Tunneled Transport Layer Security)
Metoda EAP-TTLS vychází z metody EAP-TLS. EAP-TTLS odstraňuje největší problém metody EAP-TLS, kterou je potřeba existence certifikátů pro klienty. Server je vybaven certifikátem, který klient použije k vytvoření šifrovaného TLS tunelu. V tomto tunelu je pak prováděna autentizace klienta pomocí jiného autentizačního protokolu (PAP, CHAP, MS-CHAPv2). Autentizace serveru může probíhat také v tomto tunelu, nebo se server autentizuje pouze pomocí svého certifikátu. Metoda EAP-TTLS není nativně podporována ve Windows, proto se v praxi neujala. Místo ní se používá metoda PEAPv0-MS-CHAPv2, která je z technického hlediska metodě EAP-TTLS velmi podobná. Metoda je popsaná v RFC 5281. •
vzájemná autentizace
•
server se autentizuje certifikátem
•
klient se autentizuje jiným autentizačním protokolem
•
v praxi se nepoužívá
4.2.6
PEAP (Protected EAP)
Metoda PEAP je velmi podobná metodě EAP-TTLS. PEAP vyvinuly společnosti Microsoft, Cisco a RSA Security. Jedná se o jednu, v praxi, z nejpoužívanějších metod. Existují tři verze metody PEAP. •
PEAPv0/EAP-MSCHAPv2 o vytvořen firmou Microsoft 28
o široká podpora •
PEAPv1/EAP-GTC o vytvořen firmou Cisco o chybí podpora v MS Windows, proto se skoro nepoužívá o podpora v OS Symbian
•
PEAPv2 o IETF draft o podpora pro řetězení více EAP metod, kryptografické vazby mezi vnitřním autentizačním mechanismem a tunelem o podpora pro výměnu libovolných parametrů (obecně nazývaných TLV – Tag-Length-Value) mezi klientem a serverem
EAP-PEAP pracuje ve dvou fázích: •
Fáze 1 – klient autentizuje server pomocí jeho certifikátu a dojde k vytvoření šifrovaného TLS tunelu mezi klientem a serverem.
•
Fáze 2 – uživatel nebo stroj se autentizují serveru. Autenizace probíhá skrz šifrovaný tunel vytvořený během Fáze 1. Autentizace klienta může probíhat libovolnou EAP metodou, nejčastěji pomocí EAP-MSCHAPv2 nebo EAPGTC (Generic Token Card).
•
vzájemná autentizace
•
server se autentizuje certifikátem
•
klient se autentizuje vnořenou EAP metodou (nejčastěji EAP-MSCHAPv2)
•
používaný v bezdrátových sítích WiFi
4.2.7
EAP-SIM (Subscriber Identity Module)
EAP-SIM slouží ke vzájemné autentizaci pomocí SIM karty (nebo obecně nějaké smart-karty). Požadavky na autentizaci jsou přenášené protokolem EAP-SIM přes bránu mobilního operátora do AuC (Authentication Center ) příslušné GSM sítě. Předpokládaným způsobem použití této metody měla být autentizace smartphonů roamujících mezi WiFi a GSM sítěmi. V praxi se tato metoda zatím nepoužívá. Popsána je v RFC 4186. •
vzájemná autentizace
•
roaming telefonu mezi GSM a WiFi sítěmi
•
autentizace s využitím SIM karty mobilního telefonu 29
4.2.8
EAP-AKA (Authentication and Key Agreement)
Stejná metoda jako EAP-SIM, ale určená pro mobilní sítě 3.generace (UMTS Universal Mobile Telecommunications System [http://cs.wikipedia.org/wiki/Universal_Mobile_Telecommunications_System] ), kde se používá USIM (User Service Identity Module) . USIM je ekvivalent klasické SIM karty používané v GSM sítích, který poskytuje více funkcí než SIM jako např. větší telefonní seznam, lepší způsoby zabezpečení, podporu pro aplikace uložené na USIM apod. Pro využívání UMTS sítí není USIM vyžadována, lze používat i klasické SIM karty z GSM ( a obráceně). EAP-AKA používá silnější autentizační prostředky než EAP-SIM. Popsána je v RFC 4187. •
vzájemná autentizace
•
podobné EAP-SIM
•
roaming telefonu mezi UMTS a WiFi sítěmi
•
autentizace s využitím USIM karty mobilního telefonu
4.2.9 EAP-EKE (Encrypted key exchange [http://en.wikipedia.org/wiki/Encrypted_key_exchange] ) Jedna z nejnovějších EAP metod, standardizovaná v únoru 2011 v RFC 6124. Tato metoda je založena na protokolu DH-EKE (Diffie-Helmman Encrypted Key Exchange [http://en.wikipedia.org/wiki/Encrypted_key_exchange] ). •
vzájemná autentizace
•
nevyžaduje certifikáty a PKI
•
není náchylná na slovníkové útoky.
4.2.10
EAP-IKEv2
Metoda EAP-IKEv2 je založena na protokolu IKE (Internet Key Exchange). Protokol IKE je součástí technologie IPsec, kde má na starosti dojednání klíčů. IKEv2 je zdokonalenou verzí protokolu IKE a je popsán v RFC 5996. Autentizaci je možné provádět pomocí jedné ze tří metod: •
heslo (předsdílený klíč)
•
klíč pro symetrický šifrovací algoritmus
•
pár klíčů pro asymetrický šifrovací algoritmus (ASK)
Rozdíl mezi heslem a klíčem pro symetrický šifrovací algoritmus je v množství entropie. Heslo je řetězec s nízkou entropií, zatímco klíč pro symetrickou šifru je 30
řetězec s vysokou entropií. Zajímavou vlastností IKEv2 je možnost provádět autentizaci ve směru klient-server jinak než ve směru server-klient. Kombinace, které připadají v úvahu, jsou uvedeny v tabulce.
31
3.5 AAA protokoly obecně V počítačových sítích se lze často setkat s pojmem tzv. AAA architektury (AAA – Authentication, Authorization, Accounting). Jedná se o použití komplexních protokolů, které zajišťují: •
Autentizaci
•
Autorizaci
•
Účtování
Tyto protokoly se používají spíše ve větších sítích. AAA protokoly lze obecně charakterizovat pojmy: •
nepřímá autentizace
•
centralizovaná autentizace o velké sítě o přesun autentizačních údajů z koncových zařízení na jedno místo o centrální autentizační server
Pojem autentizace již byl v rámci tohoto modulu objasněn. Jde o proces ověření identity autentizované osoby (nebo systému). Výsledkem je pak přidělení nebo odepření oprávnění k čerpání určité síťové služby (např. přístup do konkrétního informačního systému). S autorizací jste se již také setkali. Autorizace představuje určitý souhrn omezení služby, která je poskytována autentizovanému uživateli. Omezení může mít např. charakter konkrétní IP adresy, ze které lze ke službě přistupovat, časového omezení (pouze Po-Pá 8-16), množství dotazů které lze systému (např. jeden SQL dotaz do databáze za sekundu), konkrétních přístupových práv k souborovému systému (např. uživatel má právo číst existující soubory a složky, vytvářet nové, ale nemá právo mazat). Patří sem také aplikace různých QoS (Quality of Service) mechanismů, mechanismů front a priorit nebo FUP (Fair Use Policy), které jsou uplatňovány právě na základě předchozí autentizace uživatele. Účtování (Accounting) je činnost spočívající ve sledování využívání síťových zdrojů (např. množství přenesených dat, IP adresy se kterými uživatel komunikuje, doba strávená v systému, příkazy zadávané do systému,…). To se děje jednak pro potřeby fakturace (platba za poskytnuté služby – angl. billing) a také pro potřeby plánování, správy sítě nebo bezpečnostního auditu. V roli AAA protokolů se nejčastěji používají protokoly: •
RADIUS
•
DIAMATER
•
TACACS+
32
•
Kerberos
Představte si velkou nadnárodní firmu BIG-Admin a.s. jejímž předmětem podnikání je správa informačních systémů a sítí pro jiné společnosti. Jeden z jejích zákazníků – firma OstráTužka s.r.o. požaduje připojení své nové pobočky v Praze do své firemní sítě. To znamená mimo jiné provést změnu v konfiguraci centrálního směrovače firmy BIG-Admin pro Českou Republiku. Pomocí mechanismu AAA lze zajistit, že: •
přístup na centrální směrovač budou mít pouze správci z firmy BIG-Admin Jan Novák a Petr Bubák - autentizace
•
přístup na směrovač bude pouze z vnitřní sítě firmy BIG-Admin – autorizace
•
bez ohledu na aktuální vytížení směrovače bude vždy rezervována určitá šířka pásma a času CPU pro potřeby správy/administrace – autorizace
•
při pokusu o přihlášení bude uložen v logu datum, čas, IP adresa, už. jméno uživatele – accounting
•
budou zaznamenány příkazy, které uživatel zadával po přihlášení - accounting
Zejména poslední bod je důležitý v případech, kdy je ve firmě více zaměstnanců pro stejnou činnost (zde např. správců síťových prvků) a je zpětně potřeba zjistit, kdy nastala konkrétní změna, či kdo ji provedl.
33
3.6 TACASCS+ Nejstarším AAA protokolem byl TACACS (Terminal Access Controller Access Controll System). Šlo o protokol pro autentizaci v sítích na bázi IP protokolu, který vznikl pro potřeby řízení přístupu v síti ARPANET (Advanced Research Projects Agency Network ), což byla počítačová síť, kterou můžeme chápat jako předchůdce dnešního Internetu. TACACS sám o sobě nebyl nijak zabezpečený (tzn. už. jména i hesla se přenášela v otevřeném tvaru). Používal klient-server architekturu a na transportní vrstvě protokol UDP (User Datagram Protocol). Z protokolu TACACS se dále vyvinul protokol XTACACS (Extended TACACS), který přidal podporu autorizace a účtování. Poslední verzí je protokol TACSCS+ (Terminal Access Controller Access Controll System+). Protokol TACACS+ vychází ze starších protokolů TACACS/XTACACS, ale není s nimi kompatibilní. TACACS+ je proprietární protokol firmy Cisco. Proces autentizace je oddělen od autorizace, což umožňuje např. použít k autentizaci Kerberos a k autorizaci TACACS+. Na rozdíl od TACACS/XTACACS používá jako transportní protokol TCP (Transmission Control Protocol) a šifruje celý paket. Protokol TACACS+ nebyl nikdy standardizován. Existuje pouze RFC 1492 popisující původní protokol TACACS a IETF draft protokolu TACACS+ z ledna 1997, který je dostupný na adrese http://tools.ietf.org/html/draft-grant-tacacs-02 . Unixovou implementaci TACACS+ protokolu je možné získat např. přímo od firmy Cisco - ftp://ftp-eng.cisco.com/pub/tacacs/ , pro Windows pak třeba zde: http://tacacs.net
34
3.7 RADIUS a DIAMETER Pravděpodobně nejrozšířenějším AAA protokolem, který se dnes používá je RADIUS (Remote Access Dia In User Service). Radius zahrnuje všechny tři složky architektury AAA. Na úrovni transportní vrstvy používá protokol UDP. Transakce mezi serverem a klientem se autentizují pomocí sdíleného hesla, které se nikdy nepřenáší v síti. Místo něj se přenáší pouze otisk (hash) vytvořený funkcí MD5. Uživatelské heslo se mezi serverem a klienty neposílá v otevřeném tvaru, ale je zašifrováno proudovou šifrou. Jejím základem je hashovací funkce MD5 v roli PRNG (Pseudorandom Number Generator) inicializovaného tajným sdíleným klíčem. Výstup z tohoto PRNG je pak přičten operací XOR k chráněnému heslu. Na rozdíl od TACACS+ se chrání pouze samotná hesla, nikoliv kompletní obsah paketu. RADIUS je standardizován v RFC 2865 a 2866. Používá se mimo jiné jako autentizační server v IEEE 802.1x. Vzhledem k v dnešní době již nedostatečné úrovni zabezpečení, kterou RADIUS poskytuje (použití hashovací funkce MD5, pouze jednoduché autentizační schéma) se v praxi často kompletní RADIUS komunikace zapouzdřuje do IPsec tunelů. Vzhledem k možnosti definovat a používat vlastní uživatelské atributy, zde existuje možnost vzájemné nekompatibility mezi serverem a klienty. Z protokolu RADIUS vznikl protokol DIAMETER, který sice není s protokolem RADIUS přímo kompatibilní, nicméně je mu velmi podobný. Hlavními rozdíly oproti RADIUSu jsou: •
lepší zabezpečení pomocí technologie IPsec nebo TLS
•
lepší podpora pro AVP (Atribute Value Pair) – 32bitové identifikátory místo 8bitových
•
spolehlivý transportní protokol TCP nebo SCTP (Stream Control Transmission Protocol)
•
kompletní zarovnání na 32bitové hranice
•
možnost definovat vlastní AVP
•
dynamické objevování uzlů pomocí DNS a SRV záznamů
•
podpora roamingu (je již i u RADIUSu)
Název DIAMATER je zajímavou slovní hříčkou, protože původním významem slova radius je poloměr, a diametr zase znamená průměr. A protože průměr je dvakrát větší než poloměr, má i protokol DIAMETER být dvakrát lepší než RADIUS.
35
3.8 KERBEROS Kerberos je centralizovaný, síťový autentizační systém. Na rozdíl od protokolů RADIUS, DIAMETER, nebo TACACS+ nezajišťuje autorizaci ani účtování, ale pouze autentizaci, takže nepatří do kategorie AAA. Kerberos vznikal v letech 1983-1991 na MIT v USA. První veřejně dostupná verze protokolu byl Kerberos v4. V současnosti se používá novější verze Kerberos v5, který je standardizován v dokumentu RFC4120 (http://www.ietf.org/rfc/rfc4120.txt ). Kerberos se také využívá jako výchozí způsob autentizace v systémech MS Windows (od verze 2000), nicméně Microsoft používá vlastní implementaci protokolu. Protokol Kerberos lze charakterizovat pojmy: •
vzájemná autentizace
•
nepřímá autentizace
•
C-S model
•
podpora SSO (Single Sign On)
V současnosti existuje několik volně dostupných implementací: •
MIT verze - http://web.mit.edu/Kerberos/
•
Heimdal - http://www.h5l.org/
•
Shishi - http://www.gnu.org/software/shishi/
Kerberos byl v minulosti úřady v USA klasifikován jako pomocná vojenská technologie a zároveň byl zakázán jeho export, protože používal algoritmus DES [http://cs.wikipedia.org/wiki/Data_Encryption_Standard] . Tento zákaz obešla švédská univerzita KTH (The Royal Institute of Technology), která vytvořila a uvolnila vlastní implementaci protokolu Kerberos v4. Tato verze vycházela z MIT verze okleštěné od podpory šifrovacích funkcí. Tak se Kerberos dostal mimo území USA. Dnes je díky změnám ve vývozních omezeních USA, ve většině zemí možné stáhnout i MIT verzi Kerberosu. Jedním ze základních stavebních bloků protokolu jsou tzv. tickety (ticket-lístek), které se používají ke vzájemné identifikaci účastníků komunikace. Ticket má velikost řádově stovky B a je možné ho vložit do libovolného síťového protokolu. Protože tickety mají omezenou platnost, Kerberos vyžaduje přesnou časovou synchronizaci mezi jednotlivými komunikujícími entitami. Podobně jako u ostatních síťových autentizačních protokolů zmiňovaných v tomto modulu je vyžadována existence důvěryhodné třetí strany, která je zde nazývána KDC (Key Distribution Center). KDC se rozpadá na dvě logicky nezávislé entity: •
TGS - Ticket Granting Server
36
•
AS - Authentication Server
KDC využívá klasické Needham-Schröederova schéma autentizačního protokolu s důvěryhodnou třetí stranou (TTP – Trusted Third Party), které je znázorněno na obrázku. Celá autentizace má pět kroků: 1. Účastník A odešle na autentizační server (AS) požadavek na komunikaci A-B spolu s náhodným číslem NA. Číslo NA slouží k identifikaci konkrétního spojení. 2. AS vygeneruje zprávu zašifrovanou relačním klíčem KAS, který je sdílen mezi účastníkem A a AS. Zašifrovaná zpráva obsahuje: – Identifikátor spojení NA Identifikátor druhé strany – B – – Relační klíč KAB pro zabezpečenou komunikaci mezi účastníky A a B – Zašifrovanou zprávu obsahující relační klíč KAB a identifikátor účastníka A. Tato zpráva je zašifrovaná klíčem KBS, který je známý pouze účastníku B a AS. Účastník A ji nedokáže dešifrovat. 3. Účastník A odešle účastníku B zprávu s relačním klíčem KAB zašifrovanou klíčem KBS . 4. Účastník B odešle účastníku A zprávu obsahující náhodné číslo NB zašifrované relačním klíčem KAB . 5. Účastník A odešle účastníku B zprávu obsahující náhodné číslo NB+1 zašifrované relačním klíčem KAB. Tím si mohou obě komunikující strany potvrdit, že sdílejí stejný tajný klíč.
Needham-Schröederovo autentizační schéma
Veškerá komunikace, ať již vzájemně mezi jednotlivými účastníky, nebo mezi účastníkem a serverem (AS, TGS) je šifrována. Podporovanými algoritmy jsou
37
DES (Data Encryption Standard) a AES (Advanced Encryption Standard). Kerberos umožňuje výměnu šifrovacích klíčů pro přímou komunikaci mezi účastníky komunikace.
Průběh autentizace a výměny klíčů u Kerberosu
Slovní popis jednou větou: Klient se nejprve autentizuje vůči AS, poté prokáže TGS že je oprávněn žádat ticket pro danou službu, obdrží ho a poté prokáže serveru poskytujícímu danou službu, že ji může čerpat. Podrobný komentář k obrázku zobrazujícím průběh autentizace a výměny klíčů u Kerberosu: •
Krok 0 - Klient odešle do AS zprávu v otevřeném obsahující uživatelské jméno a název služby, ke které vyžaduje přístup. o Příklad zprávy: "Uživatel Jan Novák žádá o přístup ke složce TajnePlany uložené na serveru HlavniServer pomocí protokolu SMB (Server Message Block)“ o Poznámka: Do AS se neposílá ani heslo ani tajný klíč.
•
Krok 1 - AS ověří existenci daného klienta v databázi. Pokud ano odešle mu dvě zprávy: o Zpráva A: klíč relace mezi klientem a TGS zašifrovaný pomocí tajného klíče uživatele
38
o Zpráva B: TGT (Ticket-Granting Ticket) (obsahující ID klienta, síťovou adresu klienta, dobu platnosti ticketu a klíč relace mezi klientem a TGS) zašifrovaný tajným klíčem TGS o Po doručení obou zpráv A a B klient dešifruje zprávu A. Z ní získá klíč relace mezi klientem a TGS (Kklient-TGS). Tento klíč následně používá při komunikaci s TGS. o Poznámka: Klient nemůže dešifrovat zprávu B, protože je zašifrována klíčem TGS. Nyní se klient může autentizovat vůči TGS. •
Krok 2 - Při požadavku na službu, pošle klient do TGS dvě zprávy: o Zpráva C obsahující TGT ze zprávy B a identifikátor požadované služby o Zpráva D obsahující autentifikátor (skládá se z identifikátoru klienta a časové značky). Tato zpráva je zašifrovaná pomocí relačního klíče SS a TGS.
•
Krok 3 - Po přijetí zpráv C a D je TGS dešifruje pomocí příslušného relačního klíče Kklient-TGS a pošle klientovy následující zprávy: o Zpráva E obsahuje ticket Klient-Server (který zahrnuje ID klienta, síťovou adresu klienta, dobu platnosti) zašifrovaný pomocí tajného klíče SS (KSS) o Zpráva F je relační klíč Kklient-SS zašifrovaný pomocí relačního klíče KklientTGS.
•
Krok 4 - Po přijetí zpráv E a F má klient všechny potřené informace nutné k autentizaci vůči SS. Klient se připojí k SS a odešle mu dvě zprávy: o Zpráva G: ticket klient-Server zašifrovaný pomocí tajného klíče SS o Zpráva H: nový autentifikátor obsahující ID klienta, časovou značku. Tento požadavek je zašifrován relačním klíčem Kklient-SS.
•
Krok 5 - SS dešifruje pomocí svého klíče ticket G pošle klientovi zprávu potvrzující jeho identitu a ochotu mu poskytnout požadovanou službu. o Zpráva I: časová značka v nalezená ve zprávě H zvýšená o 1 a zašifrovaná pomocí relačního klíče Kklient-SS.
•
Klient dešifruje potvrzení sdíleným klíčem Kklient-SS a ověří aktualizaci časové značky. Poté může klient důvěřovat Serveru SS a začít od něj čerpat požadovanou službu.
•
Server SS poskytne klientovi požadovanou službu.
39
3.9 Závěrečný test Po krátkém oddychu a načerpání sil si ověřte nabyté znalosti. 1. Biometrické metody autentizace jsou vhodné pro identifikaci a) lidí b) počítačů c) služeb d) žádné ze zmiňovaných kategorií správné řešení: a
2. Kvalitu biometrik lze charakterizovat pomocí veličiny FRR a a) CAR b) DAR c) FAR d) SAR správné řešení: c
3. Mezi statické biometrické metody nepatří a) otisky prstů b) geometrie ruky c) analýza hlasu d) tvar duhovky správné řešení: c
4. Dobrý autentizační token by měl být a) unikátní b) nehořlavý c) výrazně barevný d) certifikovaný EU správné řešení: a
40
5. Pokud se k autentizaci používá současně více metod označujeme tento stav jako a) velkej vopruz b) vícefaktorovou autentizaci c) kvalifikovanou autentizaci d) autentizační super-rámec správné řešení: b
6. Jaký požadavek není kladen na bezpečné heslo a) obsahuje malá písmena, velká písmena, číslice a jiné znaky b) má délku minimálně 20 znaků c) nelze jej odvodit ze znalosti osoby vlastníka d) je obměňované správné řešení: b
7. Které z následujících tvrzení není pravdivé o protokolu PAP a) jednosměrná autentizace b) jednorázová autentizace c) přímá autentizace d) kontinuální autentizace správné řešení: d
8. Pojem AAA v sobě neobsahuje činnost a) autentizace b) autorizace c) účtování d) adjungace správné řešení: d
41
9. K AAA protokolům nepatří a) SSL b) RADIUS c) TACACS+ d) DIAMATER správné řešení: a
10. Protokol TACACS+ používá na transportní vrstvě protokol a) TCP b) UDP c) SCTP d) IP správné řešení: a
11. Jak protokol RADIUS chrání přenášené informace ? a) nijak b) šifruje celý paket c) šifruje pouze heslo d) šifrují se pouze pakety odesílané z klienta na server správné řešení: c
12. Mezi základní bloky doporučení 802.1x patří: a) suplikant b) certifikační autorita c) autentizátor d) autentizační server správné řešení: a, c, d
42
13. Standard IEEE 802.1x se používá k: a) Autentizaci v mobilních sítích druhé generace. b) Autentizaci v lokálních bezdrátových sítích. c) Autentizaci v lokálních sítích realizovaných technologií Ethernet (UTP, nebo optika) d) Autentizaci v mobilních sítích první generace. správné řešení: b, c
14. Která tvrzení jsou pravdivá o protokolu CHAP: a) autentizaci zahajuje server b) autentizace probíhá pouze na počátku spojení c) jedná se o protokol typu výzva-odpověď d) autentizaci zahajuje klient správné řešení: a, c
15. Která tvrzení jsou pravdivá o protokolu EAP-PEAPv0: a) klient se autentizuje protokolem MS-CHAPv2 b) server se autentizuje protokolem MS-CHAPv2 c) používá se k autentizaci klientů v bezdrátových sítích 802.11 d) server se autentizuje certifikátem X.509v3 správné řešení: a, d
16. Která tvrzení jsou pravdivá o protokolu EAP-TLS a) autentizace klienta je realizována pomocí certifikátu X.509 b) autentizace klienta je realizována pomocí už. jména a hesla c) umožňuje vzájemnou autentizaci klienta a serveru d) nepodporuje autentizaci serveru správné řešení: a, c
43