autentizační protokoly používané v PPP

Semestrální Práce autentizační protokoly používané v PPP Ondřej Zub (ozub81@seznam.cz) 14. února 2005

Abstrakt Na následujících stránkách se, jak již název práce napovídá, budu zabývat autentizačními protokoly používanými v Point to Point protokolu (PPP). Krátkým pohledem do historie se dozvíme, proč protokol PPP vznikl. Dále čtenáře velmi zběžně seznámím se samotným PPP protokolem. Hlavním těžištěm práce však budou autentizační protokoly. K čemu slouží autentizační protokoly? Odpověď se přímo nabízí k ověření uživatele. Není však jen jedna možnost. Možností je hned několik: PAP, CHAP, MS-CHAP, EAP-TLS. Pokud nevíte, či jen matně tušíte, co tyto podivné zkratky znamenají, jsou následující stránky určeny právě pro Vás. Nerad bych jen suše překládal jednotlivá RFC 1, a proto bude nedílnou součástí dalšího textu též srovnání jednotlivých metod a příklady jejich použití. 1 Request For Comments volně přeloženo jako očekáváme Vaše připomínky

Obsah 1 protokol PPP 4 1.1 stručně o PPP.......................... 4 1.2 struktura rámce PPP....................... 5 2 protokol PAP 7 2.1 konfigurace protokolu...................... 8 2.2 formát paketu........................... 8 2.2.1 požadavek autentizace.................. 9 2.2.2 výsledek autentizace................... 9 2.3 shrnutí protokolu PAP...................... 10 3 protokol CHAP 11 3.1 konfigurace protokolu...................... 12 3.2 formát paketu........................... 12 3.2.1 challenge (výzva) a response (odpověď)........ 12 3.2.2 výsledek autentizace................... 14 3.3 shrnutí protokolu CHAP..................... 14 4 protokol MS-CHAP version 1 15 4.1 formát paketu........................... 16 4.1.1 výzva a odpověď..................... 16 4.1.2 výsledek ověření..................... 17 4.2 změna hesla............................ 17 4.3 bezpečnost............................ 18 4.4 shrnutí............................... 18 5 protokol MS-CHAP version 2 19 5.1 formát paketu........................... 20 5.1.1 výzva a odpověď..................... 20 5.1.2 výsledek ověření..................... 20 5.2 změna hesla............................ 21 5.3 používané funkce......................... 21 5.4 shrnutí............................... 22 1

OBSAH 2 6 protokol EAP 23 6.1 konfigurace protokolu...................... 24 6.2 formát paketu........................... 24 6.2.1 výzva a odpověď..................... 24 6.2.2 výsledek autentizace................... 25 6.3 základní typy Request/Response paketů............ 25 6.3.1 Identity.......................... 26 6.3.2 Notification........................ 26 6.3.3 Nak............................ 26 6.3.4 MD5-challenge...................... 26 6.3.5 One-Time Password (OTP)............... 26 6.3.6 Generic Token Card................... 26 6.4 shrnutí............................... 27 7 protokol EAP-TLS 28 7.1 úvod komunikace......................... 28 7.2 průběh TLS komunikace..................... 29 7.2.1 zpráva client hello.................... 29 7.2.2 zpráva server hello.................... 29 7.2.3 sessionid......................... 29 7.3 příklady komunikace EAP-TLS................. 30 7.3.1 úspěšné ověření...................... 30 7.3.2 neúspěšné ověření klienta................ 31 7.3.3 neúspěšné ověření serveru................ 32 7.3.4 úspěšné ověření obnovení předchozí session..... 33 8 závěr 34

Seznam obrázků 1.1 struktura rámce PPP....................... 5 2.1 PAP konfigurační paket.................... 8 2.2 obecný PAP paket........................ 8 2.3 PAP Authenticate-Request paket............... 9 2.4 PAP Authenticate-Ack/Authenticate-Nak paket...... 10 3.1 CHAP konfigurační paket................... 12 3.2 CHAP Challenge a Response paket.............. 13 3.3 CHAP Success/Failure paket................. 14 6.1 EAP Request/Response paket................. 25 7.1 EAP princip použití EAP serveru............... 28 3

Kapitola 1 Point-to-Point Protocol Vraťme se v čase do listopadu roku 1989. V naší republice probíhala změna politického režimu a slovo Internet znalo snad jen několik podivínů. Avšak daleko za oceánem vznikal dokument The Point-to-Point Protocol: A Proposal for Multi-Protocol Transmission of Datagrams Over Point-to-Point Links [1], který ovlivnil mnoho miliónů uživatelů Internetu na další desetiletí. Vznikla specifikace Point-to-Point protokolu (dále jen PPP). Proč ale tento protokol vznikl? Koncem osmdesátých let zaznamenal Internet prudký nárůst počtu uživatelů podporujících protokol TCP/IP. Drtivá většina byla připojena prostřednictvím lokálních sítí (LAN), avšak pouze malé procento využívalo k přístupu připojení typu bod-bod 1. Důvodem byla absence standardizovaného protokolu, který by tuto komunikaci umožňoval. A právě proto vznikl již zmíněný dokument RFC 1134, jehož cílem bylo tuto situaci vyřešit. A nejen to. PPP protokol měl řešit také další záležitosti. Jako příklad uveďme přidělování IP adres, které bylo problémem i v sektoru LAN, tím spíše v přepínaných okruzích využívaných spojeními bod-bod. PPP protokol šel však ještě dále a zajišťoval také dohled nad konfigurací linky, testováním kvality linky, detekcí chyb či dohodě na kompresi přenášených dat. 1.1 stručně o PPP Protokol PPP lze rozdělit na tři hlavní části: 1. Metoda zapouzdření datagramů na sériových linkách. K tomuto zapouzdřování využívá PPP protokolu HDLC. 2. Rozšiřitelný Link Control Protokol (LCP) k vytvoření, konfiguraci a otestování linkového spojení. 1 typickým příkladem je vytáčené sériové připojení 4

KAPITOLA 1. PROTOKOL PPP 5 Flag 01111110 Address 11111111 Control 00000011 Protocol 16 bits Information * FCS 16 bits Flag 01111110 Obrázek 1.1: struktura rámce PPP 3. Rodina Network Control Protokolů (NCP) pro využití a konfiguraci různých vyšších síťových protokolů. PPP je navržen tak, aby jej mohlo současně využívat několik těchto protokolů. Při vytváření spojení na lince bod-bod nejprve PPP protokol zašle několik LCP paketů, které nastaví a otestují komunikaci. Dále PPP pokračuje posíláním NCP paketů, které vyberou a nastaví jeden či více protokolů síťové vrstvy. Po dokončení této konfigurace může začít komunikace na síťové vrstvě. Ukončení spojení lze provést zasláním speciálních LCP či NCP paketů. K ukončení spojení může však dojít také při nějaké další události. Příkladem takové události může být vypršení časové odezvy. 1.2 struktura rámce PPP Podívejme se nyní na strukturu rámce protokolu PPP (obrázek 1.1). Již na první pohled je zřejmé využití protokolu HDLC. Jednotlivé bity jsou posílány zleva doprava. Jaký konkrétní význam mají jednotlivá pole? Flag je tvořen jedním oktetem, který označuje začátek a konec rámce. Má vždy hodnotu 01111110 (hexadecimálně 0x7e). Address neboli adresní pole je tvořeno jedním oktetem hodnoty 11111111 (hexadecimálně 0xff). Tuto hodnotu lze interpretovat jako broadcast adresu. PPP protokol nepřiřazuje jednotlivým stanicím adresy není k tomu ani důvod, protože se jedná o spojení bod-bod. Nějaký obsah ale adresní pole mít musí. Byla tedy zvolena broadcastová adresa, která by měla být vždy snadno rozpoznána a přijata. Rámce obsahující jinou adresu, by měly být tiše zahozeny 2. Control tedy kontrolní pole obsahuje binární hodnotu 00000011. V řeči HDLC tím říkáme, že se jedná o nečíslovaný informační rámec. Rámce s jakoukoliv jinou hodnotou tohoto pole by opět měly být tiše zahozeny. Protocol hodnota tohoto pole určuje, jaký protokol je obsažen v informačním poli rámce. Konkrétní hodnoty lze nalézt v RFC 1010 [2]. 2 Nenapadá mne rozumnější překlad anglického silently discard. Chápejme tiché zahození tak, že rámec je zahozen a oznámení této akce není zasíláno zpět odesílateli.

KAPITOLA 1. PROTOKOL PPP 6 Hodnoty cxxx označují datagramy náležící LCP a přidruženým protokolům, hodnoty 8xxx sdělují, že se v informačním poli nachází některý z rodiny NCP protokolů, a konečně rozsah 0xxx identifikuje protokoly síťové vrstvy. Pole protocol je definován až protokolem PPP v HDLC žádné takové pole nenajdeme. Information čili informační pole, někdy též označováno jako datové či dokonce textové. Na rozdíl od ostatních polí nemá pevnou délku. Může obsahovat nula a více oktetů. Jak již bylo řečeno, datagram obsažený v informačním poli je identifikován hodnotou pole Protocol. Konec informačního pole je určen pomocí ukončovacího Flagu, kterému ještě předchází dva oktety zabezpečení. Výchozí maximální délka informačního pole činí 1500 oktetů, avšak jednotlivé implementace PPP mohou používat jinou maximální hodnotu. Před přenosem může být informační pole doplněno na svoji maximální délku. Je však již věcí konkrétního protokolu, jak odliší užitečnou informaci od výplňových znaků. Frame Check Sequence (FCS) je pole délky 16 bitů, jehož hlavním úkolem je detekovat chyby vzniklé při přenosu rámce. Záměrně říkám detekovat, nikoliv detekovat případně opravit, protože o opravě není ve specifikaci nic řečeno. Některé implementace PPP mohou prodloužit délku tohoto pole na dvojnásobek čtyři oktety. Hodnota pole je spočtena ze všech bitů adresního, kontrolního, protokolového a informačního pole. Nebudu se zde rozepisovat o způsobu výpočtu této hodnoty, postačí nám informace, že se jedná o zabezpečení cyklickým kódem. V dalších kapitolách již přikročím k výkladu jednotlivých autentizačních protokolů. V tomto okamžiku si musíme zapamatovat, že všechny autentizační protokoly (až na několik výjimek) patří do rodiny LCP protokolů. Pokud dále budu zobrazovat strukturu nějakého paketu, mějme na paměti, že se jedná vlastně o pohled do informačního pole rámce PPP.

Kapitola 2 Password Authentication Protocol Nejjednodušší způsob autentizace v PPP nabízí Password Authentication Protocol (PAP) [3]. Jedná se o ověření identity klienta pomocí dvoucestné výměny 1, které se provádí pouze jednou na začátku datového spojení. Po úspěšném sestavení datového spojení začne klient posílat serveru své ID a heslo. Vše opakovaně odesílá až do okamžiku, kdy server potvrdí správnou autentizaci klienta nebo stručně informuje o chybné autentizaci a celé datové spojení zruší. Nedělejme si však iluze o nějaké bezpečnosti přihlašovaní protokolem PAP. Jak ID, tak heslo jsou posílány v čistě textové podobě. Můžeme se ostatně sami přesvědčit odchycením několika úvodních paketů celé komunikace. Není zde tedy žádná ochrana před odchycením hesla a jeho pozdějším zneužitím či náhodným posíláním ověřovacích informací. Jedinou možností je kontrola četnosti pokusů o autentizaci klienta. Ověření pomocí PAPu je používáno v případech, kdy je nutná znalost ID a hesla v textové podobě např. za účelem přihlášení na vzdálený počítač. Úroveň zabezpečení je tak obdobná jako u programů typy rsh, rlogin nebo telnet. A řekněme si upřímně takové zabezpečení snad ani nelze za zabezpečení označovat. V některých implementacích, kdy je na serveru uloženo heslo v jednocestně zašifrovaném tvaru, se lze vyhnout zasílání čistě textové podoby hesla tím, že heslo stejným jednocestným algoritmem zašifrujeme již na straně klienta. Pravda, útočník tak nezíská samotné heslo, ale pouze jeho hash, nicméně i pouhá znalost hashe mu postačí k přihlášení na server, neboť server neporovnává samotná hesla, ale jejich hashe. 1 v originálním znění 2-way handshake 7

KAPITOLA 2. PROTOKOL PAP 8 Type Length Authentication Protocol 16 bits Obrázek 2.1: PAP konfigurační paket Code Identifier Data n. Length 16 bits Obrázek 2.2: obecný PAP paket 2.1 konfigurace protokolu Mluvíme-li s cizincem, úvodem konverzace se dohodneme, v jakém jazyce budeme hovořit. Také při autentizaci je nutné informovat server, jakým způsobem chceme ověřit svou identitu. Vyšleme tedy paket, který říká serveru: K mému ověření použij protokol PAP! (obrázek 2.1). Z našeho pohledu je nejzajímavější pole Authentication Protocol, které nese informaci o použitém autentizačním protokolu. Tato hodnota je též obsažena v rámci spojové vrstvy PPP, a to v poli Protocol. 2.2 formát paketu Ještě než nahlédneme pod pokličku vlastního ověření klienta, zmiňme se o obecném formátu PAP paketu (obrázek 2.2). Code určuje, o jaký typ PAP paketu se jedná. Rozeznáváme typy: Authenticate-Request (požadavek autentizace) Authenticate-Ack (autentizace úspěšná) Authenticate-Nak (autentizace neúspěšná) Identifier číselná hodnota, která pomáhá při spárování požadavků a odpovědí Length délka celého PAP paketu Data datová část, jejíž formát je určen typem PAP paketu

KAPITOLA 2. PROTOKOL PAP 9 Code Identifier Length 16 bits ID Length Pass Length Peer-ID n. Password m. Obrázek 2.3: PAP Authenticate-Request paket 2.2.1 požadavek autentizace Jak již bylo zmíněno, zahajuje proces ověřování sám klient. Začne odesílat pakety typu Authenticate-Request. Tyto pakety posílá tak dlouho, dokud nedorazí odpověď od serveru, případně dokud nevyprší volitelný čítač opakovaného odesílání paketů. Na serveru jsou dodané informace zpracovány a klient je vyrozuměn o výsledku ověření. Pro úplnost zobrazme a popišme jeden Authenticate-Request paket (obrázek 2.3). Code hodnota značící Authenticate-Request paket ID Length délka klientova jména Peer-ID klientské jméno Pass Length délka hesla Password uživatelské heslo zaslané v čistě textovém tvaru 2.2.2 výsledek autentizace Klient odesílá a odesílá pakety s požadavky na ověření své identity. Nyní je řada na serveru musí vyhodnotit klientem zaslané údaje, zkopírovat identifikátor 2 a odeslat informaci o výsledku ověření. Jakým způsobem server zkontroluje platnost jména a hesla je čistě záležitostí implementace, a proto se touto problematikou nebudu dále zabývat. Samozřejmě připadají v úvahu dvě varianty: úspěšné ověření server posílá zpět paket Authenticate-Ack a považuje fázi autentizace za ukončenou 2 Význam identifikátoru u ověřování metodou PAP není příliš zřejmý, avšak u jiných metod ověřování bude sehrávat klíčovou úlohu.

KAPITOLA 2. PROTOKOL PAP 10 Code Identifier Length 16 bits Msg Length Message n. Obrázek 2.4: PAP Authenticate-Ack/Authenticate-Nak paket neúspěšné ověření server posílá klientovi paket Authenticate-Nak a ukončuje spojení Jak takový paket Authenticate-Ack/Authenticate-Nak vypadá? Odpověď nám poskytne obrázek 2.4. Code informace, zda se jedná o ACK či NAK paket Msg Length délka pole Message Message doplňující zpráva ve formě textového řetězce. Její obsah záleží na konkrétní implementaci. Obsah tohoto pole nesmí nijak ovlivnit funkčnost celého protokolu, proto je doporučeno, aby byly použity pouze znaky ASCII z rozsahu 32-126. 2.3 shrnutí protokolu PAP Závěrem kapitoly shrňme několik základních vlastností autentizačního protokolu PAP: dvoucestnou výměnu zahajuje klient ověřování probíhá pouze v úvodu komunikace uživatelské jméno i heslo jsou zasílány v čistě textovém tvaru

Kapitola 3 Challenge-Handshake Authentication Protocol Z předchozí kapitoly již víme, že největší slabinou protokolu PAP je zasílání hesla v čistě textovém tvaru. Dále můžeme požadovat ověření nejen na samém počátku, ale také periodicky v průběhu vlastní komunikace. Zmíněné problémy se snaží řešit Challenge-Handshake Authentication Protocol (CHAP) popsaný v dokumentu RFC 1334 [3]. CHAP ověřuje identitu klienta na základě třícestné výměny, kterou zahajuje tentokrát server. Server zasílá klientovi náhodné textové řetězce (označované jako challenge), které klient hashuje svým heslem jednocestným algoritmem MD5 a výsledek zasílá zpět serveru. Server má k dispozici čistě textové heslo klienta, a tak může stejné hashování provést sám a svůj výsledek porovnat s odpovědí od klienta. Pokud obě hashe souhlasí, je ověření úspěšné, v opačném případě je celé spojení ukončeno. Klíčovou roli zde sehrávají zasílané challenge a identifikátory jednotlivých paketů. K zajištění bezpečnosti a znemožnění odchycení hesla pro pozdější použití je v každém serverem odeslaném paketu jiná challenge a paket od paketu narůstající identifikátor. Klient tedy musí do svých odpovědí důsledně kopírovat identifikátory, aby server věděl, kterou z klientovi zaslaných challenge má pro svůj vlastní výpočet hashe použít. Velký důraz je kladen na generování zasílaných challenge. Každý takový řetězec by měl být unikátní a zároveň nesnadno předvídatelný. Proč? Snaží-li se někdo kompromitovat klienta např. útokem typu Man-in- Middle 1, může si po nějakou dobu poznamenávat challenge zaslané serverem a odpovědi zaslané klientem. V okamžiku, kdy objeví, že určitá challenge byla již v minulosti zaslána a použita pro autentizaci, přestane útočník přeposílat zprávy klientovi a serveru zašle odpověď získanou ze své vlastní databáze. Od tohoto okamžiku komunikuje server nikoli s klientem, ale s útoč- 1 mezi klienta a server se vklíní útočník, který přeposílá a zároveň samozřejmě odposlouchává komunikaci mezi oběma koncovými body 11

KAPITOLA 3. PROTOKOL CHAP 12 Type Algorithm Length Authentication Protocol 16 bits Obrázek 3.1: CHAP konfigurační paket níkem, a to minimálně do doby než je serverem znova vynucena periodicky se opakující autentizace. Ještě horší scénář nastává v případě snadno předvídatelné challenge. Útočník, tvářící se nyní jako server, začne zasílat klientovi jednotlivé předpovězené challenge. Klient domnívající se, že komunikuje se serverem, respektuje žádosti serveru o svou autentizaci a poslušně zasílá hashe zpět útočníkovi. Útočník tak rychle získává množství dvojic challenge-hash, které pak může využívat ke svému ověření na serveru. Problematika výběru vhodných challenge je mj. zmíněna v dokumentu The Point-to-Point Protocol (PPP) [4]. 3.1 konfigurace protokolu Konfigurace autentizačního protokolu je obdobná konfiguraci protokolu PAP popsané v kapitole 2.1 na straně 8. Přibývá však pole označené Algorithm, které definuje jednocestný algoritmus MD5 použitý pro hashování challenge heslem klienta (obrázek 3.1). 3.2 formát paketu Obecný formát paketu se shoduje s paketem protokolu PAP znázorněným na obrázku 2.2 na straně 8. Pole Code rozlišuje však nyní rozlišuje hodnoty: Challenge (výzva) Response (odpověď) Success (úspěšné ověření) Failure (neúspěšné ověření) 3.2.1 challenge (výzva) a response (odpověď) Challenge paket zahajuje proces ověřování. Server jej zasílá tak dlouho (samozřejmě s různými challenge a identifikátory), dokud od klienta neobdrží

KAPITOLA 3. PROTOKOL CHAP 13 Code Identifier Length 16 bits Value Size Value n. Name m. Obrázek 3.2: CHAP Challenge a Response paket response nebo dokud nevyprší čítač opakovaného odesílání paketů. Jak již bylo řečeno, mohou být challenge pakety odesílány serverem kdykoliv v průběhu komunikace za účelem opětovného ověření klienta, a tedy legitimity celého spojení. Klient přijímá challenge paket, hashuje challenge svým heslem, zkopíruje identifikátor z paketu zaslaného serverem, a vše odesílá zpět serveru v paketu označeném jako response. Server obdrží response, podívá se na identifikátor, čímž zjistí, jaká byla výchozí challenge 2, provede svůj výpočet hashe a nakonec porovná svůj výsledek s řetězcem získaným od klienta. Server zasílá klientovi výsledek ověření, ať již úspěšného či neúspěšného. V praxi však může nastat situace, kdy se klient úspěšně ověří, avšak odpověď od serveru se někde po cestě ztratí 3. Server tak musí umožnit příjem a zpracování dalších response od klienta (které samozřejmě obsahují jiný identifikátor a vypočtenou hash) i po skončení fáze ověřování. Z bezpečnostních důvodů jsou okamžitě zahazovány všechny odpovědi, které obsahují již jednou použitý identifikátor. Tím je poměrně efektivně zabráněno útokům hrubou silou. Ukažme si, jak takový challenge a response paket vypadá (obrázek 3.2). Význam jednotlivých polí: Value Size sděluje délku pole Value Value v případě challenge paketu challenge řetězec, v případě response paketu obsahuje hash vypočtenou klientem Name pole sloužící pro přenos dalších údajů. Zde se ponechává úplná volnost závisející čistě na konkrétní implementaci. Může např. suplovat funkci pole Peer-ID z protokolu PAP. 2 server si dočasně pamatuje tabulku odeslaných dvojic identifikátor-challenge 3 což ostatně ve světě Internetu není nic neobvyklého

KAPITOLA 3. PROTOKOL CHAP 14 Code Identifier Message n. Length 16 bits Obrázek 3.3: CHAP Success/Failure paket 3.2.2 výsledek autentizace Výsledkem ověřování mohou opět být pouze dva stavy úspěch a neúspěch: úspěšné ověření klientem zaslaný řetězec a serverem spočítaný řetězec souhlasí, server zasílá klientovi zprávu Success neúspěšné klientem zaslaný a serverem vypočtený řetězec se liší, klient dostává zprávu Failure a server ruší spojení Success/Failure paket znázorňuje obrázek 3.3. Code rozlišuje Success a Failure paket Message zpravidla čitelný textový řetězec. Opět nesmí narušit funkčnost celého protokolu, a proto jsou i zde doporučeny pouze ASCII znaky z rozsahu 32-126. 3.3 shrnutí protokolu CHAP Shrňme opět několik základních vlastností autentizace pomocí protokolu CHAP: třícestnou výměnu zahajuje server autentizace může probíhat i v průběhu již existujícího spojení heslo je zasíláno v šifrovaném tvaru není přímo specifikován ekvivalent klientského jména server má k dispozici svoji kopii hesla v čistě textovém tvaru

Kapitola 4 Microsoft CHAP version 1 Jak už to tak bývá, úspěšné věci protokoly nevyjímaje, bývají dále rozvíjeny aby mohly být využity i v jiných prostředích, než pro která byly navrženy. Přibližně v polovině 90. let společnost Microsoft začala modifikovat protokol CHAP. Důvodem byla jeho integrace do lokálních sítí pracujících na operačních systémech Windows. Hlavním úkolem bylo odstranění situace, kdy musí na serveru být uloženo heslo v čistě textovém tvaru, dále pak umožnění vzdálené změny hesla uživatele. A tak roku vznikl dokument Microsoft PPP CHAP Extensions [5] definující protokol Microsoft CHAP version 1 (dále jen MS-CHAP). Je až s podivem, do jaké míry je tento protokol kompatibilní s protokolem CHAP. Z tohoto důvodu se v této kapitole také hojně budeme odkazovat na obrázky jednotlivých paketů uvedené výše. Jak jsme se zbavili nutnosti existence textového hesla uloženého na serveru? Na serveru se nyní nenachází heslo v čitelném tvaru, ale pouze jeho MD4 hash 1. Pokud bychom přenášeli po síti přímo tuto hash, měl by útočník velmi snadnou práci. Vezmeme proto MD4 hash uživatelova hesla a znovu ji zahashujeme pomocí challenge zaslané serverem opět algoritmem MD4. přidáme uživatelské jméno, případně i doménu, a vše společně pošleme zpět serveru. Server ví, jakou challenge nám zaslal a tak pro něj není problém zahashovat svou zašifrovanou MD4 podobu našeho hesla. Vidíme, že v roli čistě textového hesla u protokolu CHAP zde vystupuje pouze jeho MD4 hash. MS-CHAP obsahuje i některé další odlišnosti: Response paket má pole Value dále formátováno z důvodu kompatibility mezi operačními systémy Windows 95, Windows NT 3.5, Windows NT 3.51 a Windows NT 4.0. 1 Přibližně v polovině roku 2004 byly uveřejněny informace o prolomení algoritmu MD5. Může se nám zdát, že jeho starší bratříček MD4 poskytuje jen velmi slabé zašifrování. Uvědomme si však, jaký byl výpočetní výkon počítačů před 10 lety. Pro dobu vzniku protokolu MS-CHAP byly možnosti algoritmu MD4 zcela postačující. 15

KAPITOLA 4. PROTOKOL MS-CHAP VERSION 1 16 Server má možnost kontroly opakovaného zadávání hesla a umožňuje klientovi též jeho změnu. Při neúspěšném pokusu o přihlášení je klient informován o důvodu zamítnutí. 4.1 formát paketu 4.1.1 výzva a odpověď Challenge paket je identický s protokolem CHAP obrázek 3.2 na straně 13. V poli Algorithm, samozřejmě obsahuje jinou hodnotu, protože používá algoritmu MD4. Pokud klient nepodporuje MS-CHAP, pošle serveru již při úvodní konfiguraci zprávu LCP-Config-Rej. Pak je již na serveru, zda nabídne jiný způsob autentizace. V poli Name není zasílána žádná informace. Také response paket svým formátem shoduje s protokolem CHAP. Pole Value je však dále formátováno: 24 oktetů LAN Manager compatible challenge response 24 oktetů Windows NT compatible challenge response 1 oktet Use Windows NT compatible challenge response flag LAN Manager compatible challenge response obsahuje hash vypočtenou funkcí LmChallengeResponse() [5]. LAN Manager hesla mají maximální délku 14 znaků, a oproti dnešním zvyklostem nerozlišují malá a velká písmena. Klienti by tuto hodnotu neměli vyplňovat (resp. vyplnit nulami) a upřednostnit Windows NT compatible challenge response. Windows NT compatible challenge response obsahuje hash vypočtenou funkcí NTChallengeResponse() [5]. Windows NT hesla nabízejí maximální délku 255 znaků a již rozlišují velikost písmen. Use Windows NT compatible challenge response flag určuje, zda má server upřednostnit Windows NT challenge response, či použít LAN Manager challenge response. Informace poskytnuté až do této chvíle by však serveru stále nestačily k ověření uživatele. Potřebuje ještě jednu velmi důležitou věc uživatelské jméno. A právě tato informace se přenáší v poli Name. Používá se uživateli jistě dobře známá konvence [DOMÉNA\]jméno.

KAPITOLA 4. PROTOKOL MS-CHAP VERSION 1 17 4.1.2 výsledek ověření Při úspěšném ověření je zasílán success paket, která je svým formátem identický se success paketem protokolu CHAP obrázek 3.3 na straně 14. V případě neúspěchu je však situace zajímavější. Co se vlastního formátu týče, shoduje se i failure paket s protokolem CHAP. Server ale dále např. informuje klienta, proč jeho ověření odmítl. K tomuto účelu slouží pole Name, ve kterém jsou zaneseny následující informace: důvod odmítnutí je definováno mnoho chybových kódů, kterými jsou sdělovány stavy např. account disabled, restricted logon hours, password expired, no dial-in permissions, changing password povolení opakování přihlášení určuje, zda má klient možnost dalšího pokusu o autentizaci nová hodnota challenge slouží pro opakování přihlášení; není-li uvedena vypočítává se z předcházející challenge verze protokolu použitá pro změnu hesla 4.2 změna hesla Již bylo zmíněno, že protokol MS-CHAP umožňuje uživateli též změnu hesla. Změna hesla je však možná jen v případě, že vypršela platnost hesla starého a server proto posílá zprávu password expired. Klient na základě informace od serveru, že platnost hesla vypršela, odesílá change password paket, který obsahuje následující pole: Code (1 oktet) Identifier (1 oktet) napomáhá ke spárování dotazů a odpovědí Length (2 oktety) dálka change password paketu je vždy 72 oktetů Encrypted LAN Manager Old Password Hash (16 oktetů) Encrypted LAN Manager New Password Hash (16 oktetů) LAN Manager hash hesla šifrovaný poslední serverem zaslanou challenge Encrypted Windows NT Old Password Hash (16 oktetů) Encrypted Windows NT New Password Hash (16 oktetů) Windows NT hash hesla šifrovaný poslední serverem zaslanou challenge Password Length (2 oktety) udává v počtech oktetů délku nového hesla. Je-li hodnota v rozsahu 0-14, předpokládá se, že jsou platná i pole Encrypted LAN Manager Password Hash. V opačném případě

KAPITOLA 4. PROTOKOL MS-CHAP VERSION 1 18 se tato pole pokládají za neplatná a je nutné použít pole Encrypted Windows NT Password Hash. Flags (2 oktety) je využíván pouze poslední bit, který říká, zda jsou platná pole Encrypted Windows NT Password Hash. Nejsou-li tato pole platná, musí se použít Encrypted LAN Manager Password Hash. 4.3 bezpečnost Server by měl omezovat počet opakovaných pokusů o přihlášení uživatele, aby tak omezil nebezpečí útoku hrubou silou. Zejména během změny hesla je komunikace velmi citlivá, protože nová hashe hesla je šifrována pomocí textové challenge, kterou zaslal server. Vzhledem k tomu, že používáme nepříliš silný algoritmus MD4, hrozí nebezpečí, že útočník tiše odchytí naši komunikaci a následně se pokusí o rozkrytí MD4 hashe nového hesla. Proto je doporučeno aby v situacích, kdy hrozí passive eavesdropping 2, nebyly change password pakety nikdy zasílány. 4.4 shrnutí Shrňme několik základních rysů protokolu MS-CHAP ve verzi 1: integrace do sítí MS Windows shodné formáty paketů s protokolem CHAP odpadá nutnost uložení textového hesla na serveru hesla jsou nahrazena svými MD4 hashi v případě neúspěšné autentizace je klient informován o důvodu zamítnutí server může poskytnout klientovi v případě zamítnutí možnost opakovaného přihlášení je umožněna změna hesla uživatele 2 odposlouchávání komunikace

Kapitola 5 Microsoft CHAP version 2 Z protokolu MS-CHAP version 1 se ve druhé polovině 90. let vyvinul protokol Microsoft PPP CHAP Extensions, Version 2 [8] (dále jen MS-CHAPv2). Již bylo zmíněno, že MS-CHAP version 1 neoplývá velkou měrou bezpečnosti po odchytání několika paketů autentizační procedury se můžeme pokusit rozkrýt MD4 hash sloužící k autentizaci a při současném dostupném výpočetním výkonu je pravděpodobné, že nalezení MD4 hashe nebude trvat příliš dlouho (slabiny algoritmu MD4 nám k tomu jen napomohou). Pokud dále odhadneme, jak dlouhé bude pravděpodobně uživatelské heslo, doba nutná na jeho rozluštění se ještě sníží. Hlavní problém se skrývá ve vlastním výpočtu hashe. Vstupní hodnoty jsou pouze dvě: serverem zaslaná challenge a uživatelovo hashované heslo. MS-CHAPv2 se vydal cestou zvýšení vstupních parametrů vstupujících do procesu hashování, dále pak používá silnějších šifrovacích metod (oproti MD4 ve verzi 1). Kromě uživatelského hesla dále ho hashovací funkce vstupuje uživatelské jméno, serverem zaslaná challenge a klientem vygenerovaná challenge. Server navíc posílá challenge dvojnásobné délky oproti verzi 1. Ač se formáty paketů shodují s MS-CHAP a tím pádem i s CHAP, jsou z výše uvedených důvodů protokoly funkčně zcela nekompatibilní. Ostatně MS-CHAPv2 rezignoval i na zpětnou kompatibilitu se systémem LAN Manager a autentizace tedy musí probíhat způsobem Windows NT. Je možná poněkud úsměvné, že v době zpřístupnění specifikace protokolu MS-CHAPv2 veřejnosti ve formě dokumentu RFC, již měla společnost Microsoft jasný pohled na další velmi výraznou změnu autentizace uživatelů. S uvedením operačního systému Windows 2000 Server totiž výrazně rozšířila chápání Windows domény a vedle OpenLDAP a řešení společnosti Novell Netware vytvořila jednu z dalších LDAP implementací Active Directory, kde je pro autentizaci uživatelů použit protokol Kerberos ver. 5. 19

KAPITOLA 5. PROTOKOL MS-CHAP VERSION 2 20 5.1 formát paketu 5.1.1 výzva a odpověď Formálně se struktura challenge paketu shoduje s protokolem CHAP (obrázek 3.2 na straně 13). Délka challenge je zdvojnásobena na 16 oktetů. V poli Name nejsou zasílány žádné informace. Response paket se svým formátem také shoduje s protokolem CHAP, avšak pole Value je formátováno odlišně: 16 oktetů Peer-Challenge 8 oktetů rezervováno musí být nulové 24 oktetů NT-Response 1 oktet Flags Peer-Challenge je, jak již název napovídá, generována klientem. Jedná se o náhodné číslo, které by mělo splňovat všechny požadavky na dobrou challenge. NT-Response je výsledekem funkce GenerateNTResponse(), jejíž vstupní parametry tvoří uživatelské heslo, uživatelské jméno 1, serverem zaslaná challenge a lokálně vygenerovaná peer-challenge. Flags pole rezervované pro budoucí využití a jeho hodnota musí být nulová V poli Name je opět obsaženo uživatelské jméno ve formátu [DOMÉNA\]jméno. 5.1.2 výsledek ověření V případě úspěšného ověření je zasílán již známý success paket (obrázek 3.3 na straně 14). Pole Message, je však obohaceno o další informace. Prvních 20 oktetů tvoří auth string, který je odvozen z challenge, peer-challenge a NT-Response. Klient je povinnen si tuto hodnotu ověřit. Pokud tato hodnota nesouhlasí či dokonce chybí, musí klient spojení ukončit. Zbývajících 1 Zde se jedná o uživatelské jméno bez určení domény. Důsledkem je jedna z pozoruhodných vlastností systémů a domén Windows NT: Uživatel má svůj pracovní notebook, který je zařazen do NT domény A. Má přiděleno doménové uživatelské jméno a heslo. Po skončení pracovní doby přijede domů, kde má malou lokální síť, na které také existuje Windows doména B (aby se mu neprodražila je provozována na Linuxu se Sambou). V této doméně si vytvoří uživatele se stejným jménem a heslem jako je zvyklý z práce. Pustí notebook zaloguje se do domény A (vlastně spíše do svého nakešovaného profilu z domény A) a vesele může přistupovat ke všem sdíleným prostředků v doméně B. Uživatelské jméno a heslo je přece stejné a nějaká doména nás při ověřování nezajímá.

KAPITOLA 5. PROTOKOL MS-CHAP VERSION 2 21 22 oktetů pole Message obsahuje čitelnou zprávu v odpovídajícím jazyce a kódování. Není-li ověření úspěšné, zasílá server failure paket, jehož obsah je obdobný failure paketu protokolu MS-CHAP version 1. Na rozdíl od verze 1 je zde však důsledně dodržována přítomnost nové challenge v případě, že server povolí opakované přihlášení na rozdíl od starší verze tedy není možné tuto challenge odvodit od předchozí. 5.2 změna hesla Změna hesla je možná pouze při vypršení platnosti hesla starého. Toto je však poslední společný rys change password paketů MS-CHAP verze 1 a verze 2. Change password paket u protokolu MS-CHAPv2 již není podporován staršími verzemi Windows (Windows 95, Windows NT 3.51, Windows 98 Windows 98SE jej ale podporují). Paket obsahuje následující pole: Code (1 oktet) Identifier (1 oktet) Length (2 oktety) dálka change password paketu je vždy 586 oktetů Encrypted Password (516 oktetů) nové Windows NT heslo šifrované hashí starého Windows NT hesla Encrypted Hash (16 oktetů) stará Windows NT hash šifrovaná hashí nového Windows NT hesla Peer-challenge (16 oktetů) obdoba stejného pole response paketu Rezerva (8 oktetů) musí mít nulovou hodnotu NT-Response (24 oktetů) obdoba stejného pole u response paketu; zde je však již počítáno vše pomocí nového hesla a challenge z předchozího failure paketu Flags (2 oktety) rezervovány pro budoucí využití a musí být nulové 5.3 používané funkce S trochou nadsázku lze říci, že každá z výše uvedených hodnot jednotlivých polí je počítána pomocí jiné funkce. Proto jsou součástí specifikace [8] protokolu také přílohy, které tyto funkce přesně definují. Rozbor i pouhý výčet těchto funkcí je nad rámec této semestrální práce.

KAPITOLA 5. PROTOKOL MS-CHAP VERSION 2 22 5.4 shrnutí Závěrem kapitoly opět uveďme několik charakteristických rysů protokolu MS-CHAPv2: integrace do sítí MS Windows (pouze 98SE a novější, NT 4.0 a novější) shodné formáty paketů s protokolem CHAP odpadá nutnost uložení textového hesla na serveru hesla jsou nahrazena hashi v případě neúspěšné autentizace je klient informován o důvodu zamítnutí server může poskytnout klientovi v případě zamítnutí možnost opakovaného přihlášení klient si musí ověřit výsledek své úspěšné autentizace komunikace při změně uživatelského hesla je důkladně šifrována

Kapitola 6 Extensible Authentication Protocol Všechny doposud zmiňované protokoly měly jedno společné autentizace probíhala během LCP fáze, tedy ihned po navázání spojení. Extensible Authentication Protocol (dále jen EAP), popsaný v dokumentu PPP Extensible Authentication Protocol (EAP) [9], přichází se zcela odlišnou filozofií. Během LCP fáze se server s klientem pouze dohodne, že pro ověření použijí protokolu EAP. Po ukončení LCP fáze začíná autentizační fáze. Server se s klientem dohodne, jaký druh EAP autentizace použijí, a poté začne klienta zpovídat. Jedná se o sérii dotazů serveru a odpovědí klienta, jejichž výsledkem je úspěšné či neúspěšné ověření. Existuje několik důvodů proč ověřování klienta takto odložit. Jednak má server možnost získat od klienta oproti dříve zmiňovaným protokolům mnohem více informací, dále zde vzniká prostor pro použití back-end serveru. Jaká je úloha back-end serveru? Existují síťová zařízení (např. NAS 1 ), která jsou hloupá a tudíž nedokáží sama zpracovávat a vyhodnocovat ověřovací informace zaslané klientem. Tato zařízení pouze přeposílají data od klienta zmíněnému back-end serveru, který budeme dále nazývat EAP server. EAP server si vyzpovídá klienta a síťovému zařízení pak pošle pouze výsledek autentizace přístup povolen či zamítnut. Výhoda EAP serveru však spočívá zejména v centralizaci ověřování. Je tak umožněna implementace mnohem sofistikovanějších ověřovacích metod jako je např. použití jednorázových hesel, RSA karet, ověřování přes LDAP apod. Autentizační fázi lze obecně rozdělit do třech fází: 1. Po sestavení spojení a dohodě na použití EAP protokolu zašle server klientovi jednu či více EAP-Request. Každá request má označen svůj typ např. Identity, MD5-challenge, One-Time-Password. 1 Network Attached Storage 23

KAPITOLA 6. PROTOKOL EAP 24 2. Klient zasílá serveru EAP-Response, ve do které zkopíruje typ z EAPrequest a doplní serverem požadovanou informaci. 3. Poté, co server získá od klienta všechny požadované informace, zašle klientovi zprávu o výsledku autentizace. 6.1 konfigurace protokolu Konfigurační paket se shoduje s protokolem PAP (obrázek 2.1 na straně 8). Samozřejmostí je, že pole Authentication Protocol obsahuje kód protokolu EAP. 6.2 formát paketu Také obecný formát paketu se shoduje s protokolem PAP. Popišme si však znovu jednotlivá pole: Code identifikuje typ EAP paketu. Existují čtyři typy: Request Response Success Failure Identifier napomáhá ke spárování dotazů a odpovědí. Jak bude dále zmíněno, má však odlišnou funkci, zejména v porovnání s protokoly CHAP. Length udává délku celého paketu. Data obsahuje vlastní informaci, jejíž obsah a význam závisí na typu paketu. 6.2.1 výzva a odpověď Request paket zasílá server klientovi. Každý request paket má svůj typ, který určuje, jakou informaci si server žádá od klienta. Server stále zasílá klientovi request pakety až do té doby, dokud nedostane od klienta platnou odpověď. A zde se již mění význam pole Identifier. Při zasílání jednoho typu žádostí, server nemění identifikátor! Nový identifikátor totiž indikuje signalizuje novou žádost. Klient odešle serveru odpověď, do které zkopíruje identifikátor, typ paketu (např. Identity) a doplní data požadovaná serverem. Request/Response paket zobrazuje obrázek 6.1: Code určuje, zda se jedná o výzvu či odpověď.

KAPITOLA 6. PROTOKOL EAP 25 Code Identifier Length 16 bits Type Type-Data n. Obrázek 6.1: EAP Request/Response paket Type říká, jaký typ informace je poptáván/zasílán. Jedná-li se o response paket, může být také zaslána hodnota Nak, která sděluje serveru, že informaci tohoto typu klient neumí poskytnout. Type-Data obsahuje buď nějakou čitelnou zprávu od serveru či vlastní odpověď zaslanou klientem. 6.2.2 výsledek autentizace V případě úspěšné autentizace server zasílá success paket. V opačném případě zasílá failure paket, případně několik request paketů, ve kterých klienta informuje ve formě čitelné zprávy o důvodu neúspěšné autentizace. 6.3 základní typy Request/Response paketů Ověřuje-li se klient protokolem EAP, je v LCP fázi spojení pouze konstatováno, že použijeme protokol EAP. V autentizační fázi však musíme vyjednat konkrétní metodu autentizace autentizační schema. A právě typy response/request paketů tuto dohodu zprostředkovávají. Uveďme šest základních typů paketů (první čtyři typy musí být podporovány v každé implementaci protokolu EAP), které si na dalších stranách přiblížíme: 1. Identity 2. Notification 3. Nak (může být použit pouze v odpovědi) 4. MD5-challenge 5. One-Time Password 6. Generic Token Card

KAPITOLA 6. PROTOKOL EAP 26 6.3.1 Identity Tup Identity je používán pro zjištění totožnosti klienta (uživatelské jméno). V request paketu může být zaslána textová zpráva, vyzývající uživatele k zadání jeho ID. Odpověď obsahuje v poli Type-Data zadané uživatelské jméno. 6.3.2 Notification Podobně jako typ Identity může obsahovat textovou zprávu pro klienta informující např. o době platnosti hesla, důvodu neúspěšné autentizace apod. 6.3.3 Nak Zpráva Nak je povolena pouze v response paketu a sděluje serveru, že jím požadovanou informaci nelze poskytnout. 6.3.4 MD5-challenge Typ MD5-challenge velmi podobný protokolu CHAP. Request paket obsahuje v poli Type-Data serverem zaslanou challenge a response pak klientovu odpověď. 6.3.5 One-Time Password (OTP) Systém jednorázových hesel je popsán dokumentem A One-Time Password System [10]. Výzva obsahuje textový řetězec obsahující OTP challenge. Odpověď obsahuje několik uživatelem zadaných slov z OTP slovníku. 6.3.6 Generic Token Card Výzva obsahuje krátký ASCII řetězec, který uživatel opíše do karty a vygeneruje tak jiný řetězec, který se zašle v odpovědi serveru.

KAPITOLA 6. PROTOKOL EAP 27 6.4 shrnutí V předchozích odstavcích byl principiálně popsán protokol EAP. Shrňme několik jeho charakteristických vlastností: při LCP fázi spojení dochází pouze k dohodě mezi klientem a serverem, že bude později použit protokol EAP po ukončení LCP fáze dochází k fázi autentizační EAP autentizace probíhá po sérii dotazů serveru a odpovědí klienta je možné použít velkého množství autentizačních schemat konkrétní schema je vybráno až v autentizační fázi k centrálnímu ověřování lze použít EAP-serveru

Kapitola 7 EAP Transport Layer Security Protokol EAP umožňuje implementaci dalších a dalších autentizačních schemat. Jedinou podmínkou je podpora daného schematu jak klientem, tak serverem. Nic tedy nebrání, aby se pro vzájemné ověření klienta se serverem použila dvojice certifikátů, případně již během autentizační fáze byl vyjednán způsob šifrování další komunikace. A právě toto autentizační schema je popsáno dokumentem PPP EAP TLS Authentication Protocol [11] EAP využívající již existujícího protokolu Transport Layer Security (dále jen TLS). 7.1 úvod komunikace V LCP fázi je vyjednán protokol EAP. Posouváme se dále k autentizační fázi. EAP konverzace většinou začíná zasláním EAP-Request/Identity paketu serverem klientovi. Klient odesílá zpět EAP-Response/Identity paket, ve kterém serveru sděluje svou totožnost zasílá své userid. Až do tohoto okamžiku jsme komunikovali přímo se zařízením, ke kteklient (a) server (NAS) EAP server (b) Obrázek 7.1: EAP princip použití EAP serveru 28

KAPITOLA 7. PROTOKOL EAP-TLS 29 rému se chceme autentizovat (obrázek 7.1 cesta a). Již bylo zmíněno, že takové zařízení nemusí přímo podporovat námi preferované autentizační schema, a proto bude všechny další EAP pakety pouze přeposílat od klienta k EAP serveru a opačně (obrázek 7.1 cesta b). 7.2 průběh TLS komunikace 7.2.1 zpráva client hello Jakmile server od klienta obdrží EAP-Response/Identity, zasílá klientovi EAP-Request/Start-TLS. Klient odpovídá na na vrstvě protokolu TLS zprávou client hello. Zatím není při komunikaci použita žádná komprese ani šifrování (změna šifrovacích klíčů probíhá až v okamžiku výskytu zprávy change cipher spec). Zpráva client hello obsahuje informaci sessionid, náhodné číslo, seznam klientem podporovaných šifrovacích algoritmů a klientovu verzi protokolu TLS. 7.2.2 zpráva server hello Server odpovídá zprávou server hello, za kterou následuje TLS certifikát serveru, server key exchange, certificate request, server hello done, případně zpráva finished handshake a TLS change cipher spec. Samotná zpráva server hello obsahujenáhodné číslo, sessionid, šifrovací algoritmus, který bude použit pro další komunikaci, a samozřejmě verzi protokolu TLS. 7.2.3 sessionid SessionID je číslo, které identifikuje session. Má význam zejména v těch případech, kdy je tvořeno velké množství krátkých spojení 1. Pokud se uživatel již dříve autentizoval (a ještě mu nevypršel timeout), může znovu navázat na předchozí session a nemusí podstupovat celý proces autentizace znovu. Z bezpečnostních důvodů se však změní šifra použitá při komunikaci se serverem zasílá se zpráva change cipher spec. Pokud klient neposkytne platný identifikátor sessionid, vytváří server novou session a klient si bude muset projít celou autentizační fázi znovu. 1 TLS byl původně navržen pro HTTPS

KAPITOLA 7. PROTOKOL EAP-TLS 30 7.3 příklady komunikace EAP-TLS 7.3.1 úspěšné ověření klient směr server PPP LCP ACK-EAP auth PPP EAP-Response/ Identity (MyID) PPP EAP-Response/ (TLS client hello) PPP EAP-Response/ (TLS certificate, TLS client key exchange, [TLS certificate verify,] TLS change cipher spec, TLS finished) PPP EAP-Response/ PPP LCP Request-EAP auth PPP EAP-Request/ Identity PPP EAP-Request/ (TLS Start) PPP EAP-Request/ (TLS server hello, TLS certificate, [TLS server key exchange,] [TLS certificate request,] TLS server hello done) PPP EAP-Request/ (TLS change cipher spec, TLS finished) PPP EAP-Success

KAPITOLA 7. PROTOKOL EAP-TLS 31 7.3.2 neúspěšné ověření klienta klient směr server PPP LCP ACK-EAP auth PPP EAP-Response/ Identity (MyID) PPP EAP-Response/ (TLS client hello) PPP EAP-Response/ (TLS certificate, TLS client key exchange, TLS certificate verify, TLS change cipher spec, TLS finished) PPP EAP-Response/ PPP EAP-Response/ PPP LCP Request-EAP auth PPP EAP-Request/ Identity PPP EAP-Request/ (TLS Start) PPP EAP-Request/ (TLS server hello, TLS certificate, [TLS server key exchange,] TLS certificate request, TLS server hello done) PPP EAP-Request/ (TLS change cipher spec, TLS finished) PPP EAP-Request/ (TLS Alert message) PPP EAP-Failure

KAPITOLA 7. PROTOKOL EAP-TLS 32 7.3.3 neúspěšné ověření serveru klient směr server PPP LCP ACK-EAP auth PPP EAP-Response/ Identity (MyID) PPP EAP-Response/ (TLS client hello) PPP EAP-Response/ (TLS certificate, TLS client key exchange, [TLS certificate verify,] TLS change cipher spec, TLS finished) PPP EAP-Response/ (TLS change cipher spec, TLS finished) PPP EAP-Response/ (TLS Alert message) PPP LCP Request-EAP auth PPP EAP-Request/ Identity PPP EAP-Request/ (TLS Start) PPP EAP-Request/ (TLS server hello, TLS certificate, [TLS server key exchange,] [TLS certificate request,] TLS server hello done) PPP EAP-Request/ (TLS change cipher spec, TLS finished) PPP EAP-Request/ PPP EAP-Failure

KAPITOLA 7. PROTOKOL EAP-TLS 33 7.3.4 úspěšné ověření obnovení předchozí session klient směr server PPP LCP ACK-EAP auth PPP EAP-Response/ Identity (MyID) PPP EAP-Response/ (TLS client hello) PPP EAP-Response/ (TLS change cipher spec, TLS finished) PPP LCP Request-EAP auth PPP EAP-Request/ Identity PPP EAP-Request/ (TLS Start) PPP EAP-Request/ (TLS server hello, TLS change cipher spec, TLS finished) PPP EAP-Success

Kapitola 8 závěr Na předchozích stranách jsme se seznámili s několika protokoly, které lze použít pro autentizaci klienta při navazování PPP spojení. Pořadí kapitol víceméně odpovídalo i chronologii vzniku jednotlivých autentizačních protokolů. Pokusme se závěrem o stručné porovnání jednotlivých metod: PAP umožňuje elementární autentizaci uživatele. Ověřování začíná uživatel a své jméno i heslo zasílá serveru v otevřeném tvaru o nějaké bezpečnosti si může nechat jen zdát, a přece se dodnes používá. Nachází využití zejména v oblasti vytáčeného připojení k Internetu. Pryč jsou doby, kdy každý uživatel měl své jméno a heslo a kromě telefonních poplatků platil také svému poskytovateli internetového připojení. Dnes jsou vytáčeným připojením přidělena speciální telefonní čísla, jejichž tarifikace je oproti místním hovorům výrazně nižší, a jednotliví ISP poskytují veřejně informace o uživatelských jménech a heslech v tisku, televizi a samozřejmě také na svých webových stránkách. Proč tuto informaci při navazování spojení zabezpečovat, když je stejně veřejně známa? Protokol PAP dobře splní svoji funkci, je snadno implementovatelný a navíc vyniká svoji jednoduchostí a nenáročností. CHAP a z něj odvozené protokoly MS-CHAPv1 a MS-CHAPv2 již bezpečnosti přikládají větší váhu. Microsoft své protokoly integroval do svých lokálních sítí a rozšířil jejich možnosti např. o změnu hesla uživatele. První verze MS-CHAP byla velmi náchylná na únik informací při odposlouchávání komunikace zejména při změně hesla. Druhá verze tohoto protokolu zabezpečení zdokonalila, avšak na úkor komplikovanosti celého protokolu. Proto také starší operační systémy rodiny Windows tento protokol nepodporují. EAP přichází se zcela novou filozofií ověřování. Autentizace tvoří vlastní fázi komunikace, která následuje po vytvoření spojení a fázi LCP. Umožňuje jednak využití centrálního serveru ověřování, dále pak poskytuje serveru možnost získání mnohem většího počtu parametrů od klienta. Samotný EAP protokol je velmi pružný při přidávání nových autentizačních schemat, 34

KAPITOLA 8. ZÁVĚR 35 a tak umožňuje implementaci dalších autentizačních protokolů. Názorným příkladem je implementace protokolu TLS, který byl původně vyvíjen pro využití protokolem HTTPS. Stále se zvyšující výpočetní výkon běžně dostupných počítačů vede ke stále se zvětšujícímu důrazu na bezpečnost přenosu. Síťové protokoly, autentizační nevyjímaje, se neustále opravují a dále rozvíjí. Bohužel velká část protokolů zůstává uzavřená a svými tvůrci pečlivě střežená. Mnozí si odmítají uvědomit, že otevřený protokol přináší výhody také svým autorům. Otevřený protokol může být implementován do celého spektra zařízení a aplikací, a zajistí tak vzájemnou kompatibilitu i v heterogenních síťových prostředích, jejichž výskyt je dnes zejména z ekonomických důvodů velmi častý.

Literatura [1] D. Perkins: The Point-to-Point Protocol: A Proposal for Multi-Protocol Transmission of Datagrams Over Point-to-Point Links, RFC 1134 (1989) [2] J.K. Reynolds, J. Postel: Assigned Numbers, RFC 1010 (1987) [3] B. Lloyd, W. Simpson: PPP Authentication Protocols, RFC 1334 (1992) [4] W. Simpson: The Point-to-Point Protocol (PPP), RFC 1331 (1992) [5] G. Zorn, S. Cobb: Microsoft PPP CHAP Extensions, RFC 2433 (1998) [6] B. Hatch, J. Lee, G. Kurtz: Linux Hackerské útoky, SoftPress (2002) [7] L. Dostálek, A. Kabelová: Velký průvodce protokoly TCP/IP a systémem DNS 3. aktualizované a rozšířené vydání, Computer Press (2002) [8] G. Zorn: Microsoft PPP CHAP Extensions, Version 2, RFC 2759 (2000) [9] L. Blunk, J. Vollbrecht: PPP Extensible Authentication Protocol, RFC 2284 (1998) [10] N. Haller, C. Metz: A One-Time Password System, RFC 1938 (1996) [11] B. Aboba, D. Simon: PPP EAP TLS Authentication Protocol, RFC 2716 (1999) 36