Autentizační protokoly v telekomunikačních a datových

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