}w!"#$%&'()+,-./012345<ya

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY }w!"#$%&'()+,-./012345<ya Analýza autentizačních metod single sign-on v prostředí Active Directory DIPLOMOVÁ PRÁCE Bc. Jan Rejchrt Brno, jaro 2013

2 Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Bc. Jan Rejchrt Vedoucí práce: Mgr. Vít Bukač ii

3 Poděkování Tímto bych chtěl poděkovat Mgr. Vítu Bukačovi a Mgr. Pavlu Tučkovi za vedení mé diplomové práce, jejich rady, připomínky a čas který mi tím věnovali. Rád bych zde také poděkoval svým rodičům za podporu při vysokoškolském i předcházejícím studiu. iii

4 Shrnutí Cílem této práce je popsat autentizační metody využívající principu single sign-on v prostředí Active Directory. Dále se práce zabývá využitím těchto metod pro řízení přístupu k webovým stránkám z vnitřní sítě, a to za použití aktivního sít ového prvku. V rámci praktické části jsou ve virtuálním prostředí řešeny konkrétní situace. iv

5 Klíčová slova Active Directory, Kerberos, NTLM, Single sign-on, GSS-API, SPNEGO, HTTP Proxy, Squid v

6 Obsah 1 Úvod Autentizační metody v Active Directory Kerberos Architektura Autentizace důvěryhodnou třetí stranou Implementace v AD - Kerberos SSP Challenge-response protokoly typu NTLM LAN Manager NTLM verze NTLM verze NTLM a zabezpečení přenosu Single sign-on za použití NTLM Použití autentizačních mechanismů GSS-API Použití GSS-API Security Support Provider Interface SPNEGO Použití SPNEGO Negotiate SSP NegoEx SSP HTTP autentizace Princip HTTP autentizace Autentizace vůči web serveru Autentizace vůči proxy Typy autentizačních protokolů Basic autentizace Digest autentizace Pokročilé mechanismy - GSS-API/SSPI Webové proxy servery s autentizací Bezpečnostní aspekty Squid Ostatní Praktické testování Testovací prostředí Windows server Webový proxy server Klientské stanice vi

7 5.2 Scénář 1 prostá autentizace Squid vůči AD Realizace Scénář 2 řízení přístupu dle členství ve skupinách AD Realizace Scénář 3 řízení přístupu dle požadované stránky Realizace pomocí squid_ldap_group Realizace pomocí vlastního skriptu Vlastní modul - ldap_group_query.pm Závěr Literatura A Scénář 4 monitorování přihlášení uživatelů ke strojům B Modul ldap_group_query.pm vii

8 1 Úvod V dnešní době je větší či menší počítačová sít součástí naprosté většiny organizací, at jde o komerční firmu nebo jinou organizaci, například školu. Tyto sítě bývají kritické pro jejich efektivní fungování a často slouží pro přístup k důvěrným datům. Proto jde o nejčastější vektor útoků s cílem krádeže dat, ale i výpadek sítě, byt by nastal bez cizího zavinění, může napáchat citelné škody. Nejen z bezpečnostních důvodů je tedy nutné mít dostatečný přehled o dění v sítí a mít nad ní určitou míru kontroly. Velmi rozšířeným prostředkem pro správu uživatelů takových organizací je Active Directory (dále AD) pro systémy Windows společnosti Microsoft. Na toto prostředí je také zaměřena moje práce. V AD jsou používány v zásadě dva typy autentizace, první využívá protokolu ze skupiny NTLM a druhý využívá Kerbera (viz 2), přičemž tyto typy se koncepčně velmi liší. Oba ale podporují princip jednotného přihlašování (single sign-on, dále SSO) 1, jelikož jde o přístup, který je zásadní pro uživatelskou přívětivost. V práci se tedy budu zabývat jejich porovnáním z hlediska bezpečnosti a způsobu implementace SSO. Zmíněná kontrola sítě se vztahuje mimo jiné na webovou komunikaci, která muže být jedním ze zdrojů vnějších hrozeb nebo může být v některých případech považována za nežádoucí. To často závisí na identitě uživatele či samotné cílové stránce. Je tedy vhodné mít možnost tuto komunikaci regulovat pomocí aktivního sít ového prvku, typicky firewallu. Na takovémto prvku je třeba provádět autentizaci uživatelů a autorizaci jejich požadavků na webové stránky, a to co nejméně rušivým způsobem. Nabízí se tedy možnost propojení autentizace vůči AD se zmíněným mechanismem řízení přístupu k webu, a to při zachování principu SSO. První kapitola práce se věnuje teoretickému popisu autentizačních metod používaných v AD pro přihlašování uživatelů. Druhá je pak zaměřena na podpůrné mechanismy usnadňující jejich použití. Ty poskytují například jednotné rozhraní nebo postupy pro výběr společné autentizační metody. Třetí kapitola se zabývá autentizací prostřednictvím HTTP a řízením přístupu k webovým stránkám. Poslední kapitola je pak hlavně praktická a jsou zde řešeny konkrétní situace řízení přístupu s využitím autentizace vůči AD. 1. Systémy s touto vlastností umožňují na základě jednoho přihlášení přístup k více službám. Typicky je na začátku sezení provedena autentizace subjektu, která vyžaduje jeho součinnost (např. zadání hesla). Následné přístupy ke službám již mohou být prováděny automaticky bez nutnosti interakce s uživatelem, a to na základě onoho primárního přihlášení. 1

9 2 Autentizační metody v Active Directory Active Directory (dále AD) je adresářová služba, která byla uvedena v rámci operačního systému Windows 2000 Server. Slouží k uchovávání a správě uživatelů a strojů patřících do domény Windows. Zajišt uje tedy i jejich ověřování a správu práv. Vznikla jako náhrada mechanismu správy sít ových domén, který byl používán v předchozím systému Windows NT. V tomto konceptu byly jednotlivé domény na stejné úrovni, což ztěžovalo škálování a správu velkých organizací. Naproti tomu AD je hierarchický systém, kde jsou domény součástí tzv. stromů. Jednotlivé stromy pak patří do tzv. lesa. Pro autentizaci subjektů vůči AD lze využít bud mechanismus Kerberos nebo některý z protokolů typu NT Lan Manager (dále NTLM). Oba tyto mechanismy se v systémech Windows vyskytují ve formě modulů pro podporu bezpečnosti. Jde o tzv. Security Support Providers (dále SSP), konkrétně Kerberos SSP a NTLM SSP. Tyto moduly interpretují standardizované příkazy pomocí daného bezpečnostního mechanismu. Bezpečnostní prvky systému spravuje Local Security Authority (dále LSA). Jde o proces systému, který mimo jiné zprostředkovává autentizaci subjektu vůči AD. Právě tento proces volí dle systémového nastavení vhodný SSP. Pro autentizaci uživatelů a strojů vůči AD se používají zmíněné dva, ale systém běžně podporuje i další bezpečnostní moduly. Ty mohou být použity například pro autentizaci vůči webovému serveru aj. 2.1 Kerberos Mezi obecně velmi rozšířené autentizační mechanismy patří Kerberos. Jde o protokol, který využívá existence důvěryhodné třetí strany, která zprostředkovává autentizaci dvou subjektů. Jeho historie sahá do 80. let minulého století, kdy byl v rámci projektu Athena na MIT zahájen jeho vývoj. Ten vedl v roce 1989 k vydání referenční implementace jeho čtvrté vývojové verze, která byla kladně přijata a protokol našel využití v mnoha programech a operačních systémech. Kerberos 4 využíval pouze symetrického šifrování, konkrétně šlo o algoritmus DES, jehož přítomnost v implementaci také způsobovala problémy při distribuci mimo USA [20]. Další vývoj vedl k vydání specifikace Kerberos 5, která přinesla nové prvky a vylepšení. Šlo hlavně o možnost manipulovat s pověřením a vydanými lístky a podporu dalších šifrovacích algoritmů, a to i z oblasti asymetrické kryptografie. Právě verze 5 standardu je dnes hojně využívána a bude 2

10 2. AUTENTIZAČNÍ METODY V ACTIVE DIRECTORY se k ní vztahovat další popis. Byla také implementována společností Microsoft jako doménový autentizační mechanismus počínaje vydáním systému Microsoft Windows Velké rozšíření protokolu a jeho modifikací způsobilo, že mu sama MIT již nemohla poskytnout dostatečnou finanční podporu. V roce 2007 tak bylo založeno MIT Kerberos Consortium, které má podporovat jeho další vývoj [9]. Základní pricipy Mechanismus autentizačního systému Kerberos vychází z protokolu Needham Schroeder, z kterého převzal některé základní vlastnosti. Jde o princip důvěryhodné třetí strany, která autentizaci subjektů zprostředkovává a tvoří centrální bod pro správu. K samotnému ověření je zde použito šifrování a jejich tajná informace tak není přenášena přes sít, což omezuje možnosti útočníka ji získat. Z principu také poskytuje oboustrannou autentizaci a klient tak může zároveň ověřit identitu služby. Předpokladem použití systému je, že všechny subjekty (uživatelé, stroje, služby) navázali s centrem určitý vztah důvěry. Typicky jde o sdílení šifrovacího klíče, ale u asymetrické kryptografie může tento vztah představovat důvěryhodné předání veřejného klíče. Z důvodu zjednodušení se následující popis Kerbera vztahuje pouze na použití symetrické kryptografie Architektura Základním prvkem architektury Kerbera je Centrum distribuce klíčů (Key distribution center, dále KDC). To lze rozdělit na Autentizační server (Authentication server, dále AS) a Server pro vydávání lístků (Ticket granting server, dále TGS). AS zajišt uje vydání speciálního typu lístku, tzv. Ticket granting ticket (dále TGT), a ověření účtu subjektu. Provádí tak obdobu přihlášení uživatele, tedy jeho autentizaci. TGS naopak vydává lísky pro konkrétní služby na základě platného TGT. Kontroluje tedy práva subjektu přistupovat k požadované službě a provádí tak jeho autorizaci. Toto rozdělení je spíše logické než fyzické, protože obě části se z pravidla nacházejí na stejném stroji. Někdy se ještě jako samostatná část zmiňuje databáze pro uchování dat [20]. Lístky Lísky, které jsem zmínil v předchozím odstavci, tvoří významný prvek v architektuře Kerbera. Stejně jako lístky v běžném slova smyslu umožňují pří- 3

11 2. AUTENTIZAČNÍ METODY V ACTIVE DIRECTORY stup k nějaké službě. Jde o datovou strukturu, která obsahuje zašifrovanou část. Lísky vydává klientům vždy nějaká část KDC a konkrétní klient se jím může prokázat konkrétní službě. Přestože je lístek na požádání vydáván klientovi, šifrovanou část může dešifrovat pouze služba, pro kterou je určen. A to klíčem, který dlouhodobě sdílí s KDC. - verze lístku - jméno služby (principal name) - jméno domény (realm name) - příznaky (flags) - šifrovací klíč (session key) - jméno uživatele (principal name) - jméno domény (realm name) - cesta tranzitní autentizace - čas autentizace - konec platnosti - volitelné položky Obrázek 2.1: Struktura lístku Kerbera Volně přístupná část obsahuje pouze identifikátor služby, resp. její domény. Identifikátor klienta se pak nachází v šifrované části. Hlavním prvkem této části je krátkodobý šifrovací klíč vygenerovaný KDC, který je tímto způsobem předán službě. Dále je zde zašifrován časový údaj o vydání lístku, případně i začátku jeho platnosti, a konci jeho platnosti. Je tu i seznam domén použitých při autentizaci uživatele přes tranzitivní vztah důvěry mezi doménami. Důležitým prvkem jsou také příznaky. Ty určují typ lístku a tedy to, jak je s ním možné zacházet. Základní volby jsou [17]: renewable - kromě konce platnosti obsahuje takový lístek i dobu, během které je možné platnost obnovit bez nutnosti autentizace. Není tak třeba vydávat lístek nový a generovat nový krátkodobý klíč. proxiable/forwardable - oba tyto typy umožňují převézt stávající lístky na jiné umístění v síti. Při nastaveném proxiable příznaku je možné vydávat pro jiný stroj jen nové běžné lístky. U forwardable pak lze na základě původního TGT vydat i nový TGT a ten pak používat na jiném stroji. To vše bez dodatečné autentizace. Typické využití forwardable je vzdálené přihlášení k jinému počítači. V tomto případě může klient na tomto stroji přistupovat ke zdrojům při zachování SSO. Pomocí proxiable lze pak například zpřístupnit sít ové tiskárně soubor 4

12 z úložného prostoru klienta. 2. AUTENTIZAČNÍ METODY V ACTIVE DIRECTORY postdated - v tomto případě lístek obsahuje i volitelné pole po počátek platnosti. Nemusí tedy platit hned od okamžiku vydání, jeho platnost může být odložena. initial - takto označený lístek nebyl získán na základě TGT, ale přímo na základně tajemství klienta. Tedy bez použití SSO. Služba si tímto způsobem může zajistit, že klient byl nedávno autentizován. Přirozeně je tento příznak běžně nastaven u TGT. Jako speciální lístek lze označit TGT, který je vydáván jednou části KDC pro pozdější autentizaci klienta vůči druhé části KDC Autentizace důvěryhodnou třetí stranou Základní postup je následující: Klient A se chce autentizovat vůči službě B a komunikovat s ní bezpečným způsobem. Klient tedy požádá KDC o vystavení pověření. KDC zkontroluje účet klienta a vygeneruje nový šifrovací klíč (session key) pro komunikaci klienta A se službou B. Tento klíč pak předá klientovi ve dvou podobách. Jednou je lístek, který je šifrovaný dlouhodobým klíčem sdíleným se službou B (long-term key). Druhou kopii pak KDC zašifruje klíčem sdíleným s klientem A. Zprávy pochopitelně obsahují časové známky a další položky. Klient A obdrží obě části zprávy a pomocí svého dlouhodobého klíče je schopen jednu část dešifrovat a získat klíč, který vygenerovalo KDC. K obsahu lístku přístup nemá. V tuto chvíli se klient prokázal tím, že použil svůj klíč a dešifroval zprávu. Zároveň ví, že zprávu mohlo správným dlouhodobým klíčem zašifrovat jen KDC. Nyní klient A zahájí komunikaci se službou B. Té pošle taktéž dvě zprávy. Jde o lístek, který získal od KDC, a autentizační zprávu, která obsahuje časovou známku a je zašifrována krátkodobým klíčem pro komunikaci A s B. Služba B svým dlouhodobým klíčem dešifruje lístek a získá klíč pro komunikaci s klientem A. Ve správnost tohoto klíče může věřit, protože svůj klíč sdílí pouze s KDC. Takto získaný krátkodobý klíč použije pro dešifrování druhé zprávy od klienta A. Pokud získá smysluplnou zprávu, ví, že i klient A byl schopen získat krátkodobý klíč. Obě strany se tedy prokážou svou schopností získat a použít krátkodobý klíč vygenerovaný KDC [20]. 5

13 2. AUTENTIZAČNÍ METODY V ACTIVE DIRECTORY Klient A 1. Žádost o TGT 2. TGT + klíč pro A 3. Žádost o lístek pro službu B 4. Lístek pro B + klíč pro A AS TGS KDC Centrum distribuce klíčů Autentizační server Server pro poskytování lístků 5. Lístek pro službu B 6. Potvrzení přístupu ke službě Služba B Obrázek 2.2: Nákres architektury Kerbera Dvouúrovňová hierarchie pro SSO Tento základní postup je aplikován na 2 úrovních a tvoří tak určitou hierarchii. Na první úrovni se klient autentizuje vůči KDC, respektive AS, za použití svého dlouhodobého klíče. Jde o formu přihlášení do systému, na základě kterého získá subjekt TGT. Na druhé úrovni se pak subjekt prokazuje právě získaným TGT a KDC, resp. TGS, mu na jeho základě vydává lístky pro konkrétní služby. Zmíněné hierarchické členění je právě tím, co umožňuje využívat principu SSO. Subjekt totiž používá své tajemství jen na první úrovni, zbytek je možné provádět automaticky a transparentně Implementace v AD - Kerberos SSP Implementace použitá v AD odpovídá specifikaci RFC1510 a pozdější RFC4120, tedy Kerberos v5. Obsahuje sice i vlastní rozšíření, ale je stále kompatibilní s implementacemi, které splňují standard. Příslušná služba pro vydávání lístků je přístupná na každém doménovém řadiči (domain controller, dále DC) AD, přičemž poskytuje funkcionality AS i TGS [36]. Kerberos je nastaven jako výchozí autentizační mechanismus v OS Windows 2000 Server a pozdějších verzích. Jako úložiště dat o klientech využívá adresářovou službu [33]. Autentizováni jsou jak uživatelé, tak stroje. U uživatelů je jako tajemství většinou použit hash hesla, který je vytvářen stejným způsobem jako v případě NTLM. Je ale možné využít i čipových karet a asymetrické kryptografie. 6

14 Typy autentizačních přenosů 2. AUTENTIZAČNÍ METODY V ACTIVE DIRECTORY Kerberos provádí 3 typy výměny zpráv, které bývají označovány jako jeho podprotokoly [6]. Práce Kerbera začíná ve chvíli, kdy LSA obdrží autentizační údaje klienta, které lze použít k šifrování. U uživatele se typicky jedná o NTLM hash zadaného hesla, ale šifrovací klíč nemusí být dostupný přímo. V případě použití karty smart card s uloženým soukromým klíčem může LSA požádat o zašifrování dat, ale k samotnému klíči přístup nemá. Tyto autentizační údaje jsou následně zpřístupněny modulu SSP Kerberos pro iniciální autentizaci vůči KDC. Ten nejdříve pomocí protokolu DNS zjistí IP adresy DC příslušné domény. Pro komunikaci s ním pak využije první ze tří komunikačních pod-protokolů, tj. Authentication service exchange protokol. V SSP Kerberos je ve výchozím nastavení vyžadována tzv. preauntentizace. To znamená, že již iniciální požadavek zaslaný serveru (KRG_AS_REQ zpráva) obsahuje část šifrovanou klíčem klienta. Zpráva zaslaná AS části KDC obsahuje identifikátor klienta, jeho domény a časovou známku zašifrovanou dlouhodobým klíčem klienta (longterm key). Tímto způsobem KDC explicitně ověří klientovu identitu na rozdíl nastavení bez pre-autentizace, kdy o správnosti klientova klíče není přímo informován. DC v databázi AD ověří platnost účtu klienta a jeho klíčem dešifruje zbytek zprávy. Pokud vše souhlasí a časová známka není starší než nastavený limit, klient je ověřen. KDC vygeneruje nový šifrovací klíč pro komunikaci s TGS částí (session key). Tento klíč zašifruje dlouhodobým klíčem klienta a spolu s TGT odešle (KRB_AS_REP zpráva). Zmíněný TGT obsahuje také nově vytvořený klíč, ale ten je pro změnu zašifrovaný dlouhodobým klíčem KDC a nikdo jiný k němu tedy nemá přístup. Obě části zprávy obsahují časové známky [36]. Ve stručnosti na začátku této fáze může klient využívat pouze svůj dlouhodobý klíč. Na konci získá krátkodobý klíč pro komunikaci s TGS a TGT. Dlouhodobý klíč už klient nebude muset používat až do vypršení platnosti TGT. Pokaždé, když klient přistupuje k nové službě, musí kontaktovat TGS část KDC a zažádat si o příslušný lístek. K tomu využije Ticket-granting service exchange pod-protokol. Žádost (KRB_TGS_REQ zpráva) obsahuje identifikátor požadované služby, TGT a ověřovací zprávu (authenticator). Ověřovací zpráva obsahuje časovou známku zašifrovanou krátkodobým klíčem pro komunikaci s TGS. Předpokládá se tedy, že klient již získal od AS části KDC tento klíč i TGT. 7

15 2. AUTENTIZAČNÍ METODY V ACTIVE DIRECTORY Stanice klienta A klíč klienta A - jméno klienta - doména klienta timestamp KRB_AS_REP KRB_AS_REQ TGT nový klíč A TGS - parametry TGT KDC - Autentizační server klíč KDC (AS TGS) klíč klienta A GEN nový klíč A TGS Obrázek 2.3: Authentication service exchange [3] TGS zprávu příjme a nejdříve dešifruje obsah TGT, který je šifrovaný jeho dlouhodobým klíčem. Získá tak krátkodobý klíč pro dešifrování ověřovací zprávy. Proběhne-li kontrola v pořádku, TGS zjistí z AD, zda má klient přístup k požadované službě. Následně vygeneruje krátkodobý klíč pro šifrování komunikace mezi klientem a službou (service session key). Tento klíč pošle šifrovaně klientovi. V rámci stejné zprávy (KRB_TGS_REP) pošle i nový lístek pro požadovanou službu. Lístek je zašifrovaný dlouhodobým klíčem služby a obsahuje kopii stejného krátkodobého klíče, který současně obdrží klient. Klient zde tedy použil TGT a krátkodobý klíč pro komunikaci s TGS. Na jejich základě mu TGS poskytl nový lístek pro požadovanou službu a šifrovací klíč pro komunikaci s ní. Stanice klienta A klíč klienta A klíč A TGS TGT - žádost o službu B timestamp KRB_TGS_REQ KDC Centrum distribuce klíčů klíč KDC (AS TGS) klíč služby B TGT klíč A TGS - parametry TGT A TGS z TGT KRB_TGS_REP Lístek pro B nový klíč A B - parametry lístku nový klíč A B GEN Obrázek 2.4: Ticket-granting service exchange 8

16 2. AUTENTIZAČNÍ METODY V ACTIVE DIRECTORY Client-server authentication exchange představuje poslední typ komunikace Kerbera. Provádí autentizaci klienta k požadované službě, tedy to, o co klient od začátku usiloval. Klient tedy pošle službě (KRB_AP_REQ zpráva) příslušný lístek spolu s ověřovací zprávou (authenticator). Ověřovací zpráva stejně jako v předchozím případě obsahuje časovou známku, která je tentokrát zašifrována krátkodobým klíčem pro komunikaci klienta a služby (service session key). Služba tento klíč získá dešifrováním lístku, který obdržela. Po kontrole časového údaje je klientovi povolen přístup ke službě (KRB_AP_REQ zpráva) [36]. Stanice klienta A - přístup k B Služba B klíč klienta A klíč A TGS Klíč A B timestamp Lístek pro B klíč A B KRB_AP_REQ klíč služby B A B z lístku TGT lístek - B - parametry lístku KRB_AP_REP - volitelná zpráva pro vzájemnou autentizaci potvrzení přístupu Obrázek 2.5: Client-server authentication exchange Autentizace za hranice domény KDC na doménovém řadiči může přímo poskytovat autentizační služby pouze subjektům ze své vlastní domény. Aby se autentizoval, musí klient kontaktovat DC své domény, i když se právě nachází v jiné. Stejně tak přístup ke službě může autorizovat pouze DC, do kterého příslušná služba patří. Možnost vytvářet doménovou hierarchii je jedna ze základních vlastností AD, a klient tedy musí mít možnost přistupovat ke službám jiných domén bez narušení principu SSO. Z toho to důvodu je možné do klasické 2-úrovňové hierarchie Kerbera přidávat další pomyslné vrstvy. Aby mohl být klientovi z domény A poskytnut přístup ke službě z domény B, musí mezi těmito doménami existovat vztah důvěry. Ten je v prostředí Kerbera tvořen tradičně sdílením šifrovacího klíče (inter-realm key). Doména A ale nemusí sdílet klíč přímo s B, vztah důvěry může být vytvořen tranzitivně, prostřednictvím dalších domén. Přímá důvěra je automaticky vytvářena při přidávání domény do stromu, a to s nadřazeným uzlem. V případě potřeby je pak nalezena nejkratší cesta stromem od domény 9

17 2. AUTENTIZAČNÍ METODY V ACTIVE DIRECTORY A k B. Ve větších organizacích může taková cesta vést přes příliš mnoho uzlů, a tak je možné vytvořit vztah mezi doménami explicitně pomocí tzv. zkratek. Nutno dodat, že vztah obecně nemusí být oboustranný, ale může být i v jednom směru. Postup začíná stejně jako obvykle. Klient se nejdříve autentizuje vůči KDC své domény. Získá TGT a krátkodobý klíč pro komunikaci s KDC. Následně odešle KDC své domény žádost o lístek požadované služby. Skutečnost, že je služba v jiné doméně, sdělí pomocí příznaku. Na základě této žádosti zjistí KDC nejkratší cestu k cíli a následující doménu, se kterou má přímý vztah důvěry. Z přijatého TGT vytvoří nový TGT právě pro tuto doménu. TGT je šifrován jejich sdíleným klíčem, postup je podobný vydání běžného lístku a využívá podprotokol TGS Exchange. Tento postup se opakuje, dokud klient nezíská TGT pro doménu, ze které pochází požadovaná služba. Zde pak požádá o běžný lístek [3]. 2.2 Challenge-response protokoly typu NTLM Alternativou Kerbera pro přihlašování do AD jsou protokoly z rodiny NTLM. Před vydáním operačního systému Microsoft Windows 2000 to totiž byl hlavní autentizační mechanismus v doménovém prostředí MS Windows. Některé starší služby nebo systémy, které nedpodporují Kerberos, proto vyžadují tento způsob autentizace. Základem všech protokolů této skupiny je použití hashovací funkce na heslo klienta a uložení hashe v AD. Pro autentizaci se fakticky používá onen hash a musíme tedy k němu přistupovat stejně jako k heslu v čitelné podobě. Samotná autentizace je pak založena na principu výzva-odpověd (challenge-response 1 ). 1. Princip autentizace, při kterém subjekt nejdříve pošle protistraně žádost o autentizaci. Protistrana následně zašle tzv. výzvu, na kterou musí subjekt správně odpovědět. Odpověd je tedy vázána na konkrétní výzvu a nemělo by být možné ji předvídat. 10

18 2. AUTENTIZAČNÍ METODY V ACTIVE DIRECTORY 1. Požadavek na přihlášení 2. Výzva doménového řadiče 3. Odpověď klienta - LM hash - NTLM hash Obrázek 2.6: výzva-odpověd V tomto případě je první zprávou žádost o přihlášení zaslaná na DC. Ta obsahuje jméno uživatele, které zadal do přihlašovacího dialogu, a případně i další informace. Na základě žádosti DC vytvoří a odešle výzvu (nonce), která je zpravidla náhodná nebo založená na časové známce. Na heslo, které uživatel zadal při přihlašování, je aplikován příslušný hashovací algoritmus. Výsledná hodnota se pak použije pro zašifrování obdržené výzvy. Výsledek je odeslán zpět na DC. Ten použije hash uživatelova hesla, který má uložený v databázi, a taktéž provede zašifrování stejné výzvy. Pokud se výsledek shoduje s hodnotou obdrženou od klienta, klient zadal správné heslo a je ověřen. Jelikož se jedná o proprietární protokoly, Microsoft zpočátku nezveřejňoval jejich dostatečně podrobné specifikace. Proto dříve získávali například vývojáři některých open source nástrojů informace pomocí reverzního inženýrství existujících implementaci (viz [21]). Přestože je třeba považovat specifikace aktuálně poskytované firmou Microsoft (viz [10]) za důvěryhodnější a aktuálnější, představují tyto informace cenný zdroj LAN Manager Jedná se o nejstarší ze zmíněných autentizačních mechanismů. Poprvé se objevil v systému Microsoft LAN Manager a byl také hojně využíván ve starších verzích operačního systému MS Windows pro správu hesel [37]. Jako hashovací algoritmus se zde využívá LM hash, který se vyznačuje špatným návrhem a mizivou bezpečností. Délka hesla je zde omezena na 14 znaků, které jsou navíc před zpracováním převedeny na velká písmena. Po případném dorovnání na 14 znaků je heslo rozděleno na dvě poloviny. Každá část je nezávisle použita pro zašifrování konstantního bloku dat pomocí DES, kde slouží jako 56-ti bitový klíč. Zřetězení obou výsledků tvoří 11

19 2. AUTENTIZAČNÍ METODY V ACTIVE DIRECTORY 16-ti bajtový LM hash [25]. Při procesu autentizace zašle server výzvu (server challenge) tvořenou 8 bajty. LM hash zadaného hesla je doplněn nulami na 21 bajtů a rozdělen na 3 části. Podobně jako při výpočtu samotného hashe jsou tyto části použity jako šifrovací klíč pro DES. Šifrovanými daty je ve všech třech případech výzva serveru a zřetězené výsledky tvoří 24-bitovou odpověd. 14 ASCII char MojeHeslo constant KGS!@#$% 8 Bytes Server Challange 7 Bytes MOJEHES DES 7 Bytes LO DES 7 Bytes 7 Bytes 7 Bytes xxxxxxx xxxxxxx xx DES DES DES 8 Bytes 8 Bytes LM hash 8 Bytes 8 Bytes 8 Bytes LM version 1 Response 24 Bytes LM version 1 Response Obrázek 2.7: Lan Manager Na chvíli pomiňme fakt, že algoritmus DES již nelze považovat za bezpečný a nebyl primárně navržen pro tvorbu hashů. Již při převodu hesla na velká písmena je zde značně zmenšen prostor možných hesel, která mají navíc omezenou délku. K heslu není přidávána žádná proměnná hodnota (sůl). Dále je pro výpočet hashe použit ECB mód DES algoritmu, první část hesla tedy neovlivní výpočet druhé. K útoku na heslo lze tak použít tzv. rainbow tables 2 vytvořené jen pro 7 znaků. Podobný problém je při výpočtu odpovědi na výzvu serveru, kdy jsou 3 bloky odpovědi na sobě nezávislé. Přenos dat mezi klientem a serverem samotný LAN manager nijak nezabezpečuje a autentizace je tak náchylná na odposlech a man-in-the-middle 3 útok [37]. Starší verze Windows Server ve výchozím nastavení tyto hashe použí- 2. Útok, který spočívá v předpočítání výsledných hashů pro velké množství vstupních hodnot, případně i pro celý prostor. Při získání hashe lze prostým prohledáním tabulky zjistit vstup, či množinu vstupů. 3. Útok na komunikaci mezi stranou A a B. Útočník naváže spojení se stranou A i se stranou B tak, že se strany domnívají, že komunikují jen mezi sebou. To útočníkovi dovoluje aktivně vstupovat do jejich vzájemné komunikace. 12

20 2. AUTENTIZAČNÍ METODY V ACTIVE DIRECTORY valy paralelně spolu s novějším NTLM. Později byla přidána možnost toto chování zakázat, nebo naopak LM explicitně povolit v rámci úrovní kompatibility. Povolení tohoto mechanismu jednoznačně nelze doporučit. Mohlo by totiž vést k velmi jednoduchému odhalení hesla klienta, a tedy ohrožení i služeb, které používají bezpečnější mechanismus NTLM verze 1 Spolu s uvedením MS Windows NT byla vytvořena upravená verze autentizačního algoritmu, NT LAN Manager (dále NTLMv1). Ta řešila některé nedostatky LM týkající se hlavně zpracování hesla. Tento algoritmus umožňuje heslo dlouhé až 128 znaků při použití Unicode kódování (LM povoloval pouze ASCII). Při výpočtu hashe pak nedochází k žádnému dělení hesla a je přímo použit algoritmus MD4. Výsledný NTLMv1 hash má 16 bajtů, tedy stejně jako v případě LM. Stejný zůstal i postup zpracování výzvy serveru, a to se všemi jeho nedostatky [37]. 128 Unicode char MojeHeslo 7 Bytes 7 Bytes 7 Bytes xxxxxxx xxxxxxx xx 8 Bytes Server Challange MD4 16 Bytes NTLM v1 hash DES DES DES 8 Bytes 8 Bytes 8 Bytes NTLM version 1 Response LM v1 Response NTLM v1 Response Obrázek 2.8: NTLM verze 1 NTLM tedy přináší pouze změnu hashovacího algoritmu a parametrů hesla. MD4, přestože je evidentně silnější než LM hash, je v dnešní době považován za zastaralý a slabý. Co se týče autentizace, stále není při výpočtu třetí části odpovědi použito řetězení bloků a tato odpověd záleží pouze na výzvě serveru. Pro napadení hashe lze použít útoky hrubou silou, slovníkové útoky a útoky založené na rainbow tables. Stejně tak je zranitelný i autentizační protokol, který lze napadnout například přehráním dříve získané odpovědi (replay attack). Přibližně od roku 2001 je veřejně znám man-in-the-middle útok cílený na použití 13

21 2. AUTENTIZAČNÍ METODY V ACTIVE DIRECTORY NTLMv1 v rámci protokolu SMB pomocí nástroje SMBRelay 4. Při tomto útoku útočník E přepošle autentizační zprávy mezi klientem A a cílenou službou B, načež komunikaci s klientem ukončí a jeho připojení ke službě B unese. Variantou toho útoku je situace, kdy cílovou službou samotný klient, ten pak provede autentizaci vůči sobě. Na tento útok reagoval Microsoft v roce 2008 [7], přičemž bylo pouze zamezeno přeposílání autentizačních dat zpět samotnému klientovi, nikoliv třetím stranám. Proti tomuto útoku je možné se bránit zabezpečením kanálu podepisováním nebo šifrováním zpráv, aby útočník nemohl unesený kanál využít. První verze NTLM je tedy fakticky spíše opravou jednoho z nedostatků LM než novým autentizačním protokolem NTLM verze 2 Druhá verze NTLM (dále NTLM v2), vydaná ve 4. opravném balíku MS Windows NT 4.0, přináší zásadnější změny do procesu tvorby hashe i autentizace. Parametry hesla a výpočet NTLM v2 hashe jsou zde shodné s první verzí, tím však podobnost končí. Vytvořený hash je následně použit jako klíč pro HMAC-MD5, kterým je zpracován řetězec tvořený jménem uživatele a jeho domény. Výsledkem je NTLM v2 hash typické délky 16 bajtů. Upraven byl i proces zpracování výzvy serveru. K té je nově připojen blok dat proměnné délky vytvořený klientem, který obsahuje mimo jiné časovou známku a náhodná data. Obě tyto části jsou zpracovány pomocí HMAC-MD5, kdy NTLM v2 hash slouží jako klíč. Odpovědní zpráva serveru má tedy 2 části. Jedna je výsledkem hashování a druhou tvoří blok dat vygenerovaný klientem [37]. 4. Nástroj SMBRealy byl vložen jako modul i do nástroje Metasploit. SMBRelay v1 a v2 lze nalézt například zde [12]. SMBRelay3, což je nezávislá implementace stejného útoku podporující více protokolů, lze nalézt zde [15]. 14

22 2. AUTENTIZAČNÍ METODY V ACTIVE DIRECTORY 128 Unicode char MojeHeslo USERNAME+ DOMAIN 16 Bajtů NTLM v1 hash? Bytes Client Challange 8 Bytes Server Challange Server Challange HMAC MD5 16 Bajtů NTLM v2 hash HMAC MD5 16 Bytes NTLM v2 Response LM v2 Response NTLM v2 Response Client Challange Obrázek 2.9: NTLM verze 2 Co se týče hashování hesla, použitý algoritmus HMAC-MD5 nelze označit jako prolomený, ale od jeho užívání se upouští [34]. V každém případě zde stále platí, že k uloženému hashi je nutné se chovat stejně jako k heslu v čitelné podobě. Autentizační algoritmus NTLMv2 je nejvyspělejší z rodiny NTLM, což ale nezaručuje jeho bezpečnost. Proměnná délka výzvy, na níž se podílí klient i server, poskytuje větší odolnost proti některým útokům. Konkrétně použití rainbow tables či prosté ukládání odchycených výzev a odpovědí by zde bylo značně nepraktické. I NTLMv2 se ale ukázal náchylný vůči útoku man-in-the-middle podobně jako jeho předchůdce. Útok byl prezentován na bezpečnostní konferenci DEFCON 16 za použití podvodného HTTP serveru Squirtle [14]. Při tomto útoku bylo nutné přimět klienta, aby byl ochoten se k tomuto serveru autentizovat pomocí IWA. HTTP server si takto mohl odchytit více klientů, které pak mohl opakovaně využívat pro man-in-the-middle útoky na cílové služby. Proti následkům útoku se lze bránit zabezpečením přenosového kanálu, další informace lze najít v [22]. Rozšířená verze tohoto útoku byla prezentována také na DEFCON 20 s odkazem probíhající vývoj nástroje ZackAttack [18]. Dále je znám problém s náhodností generovaných výzev ve službě SMB, který existuje od počátku vydání NTLM a byl opraven teprve nedávno. Nedostatek entropie výzev zde způsoboval náchylnost vůči útokům přehráním a možnost výzvy předvídat [23]. 15

23 NTLM2 Session Response 2. AUTENTIZAČNÍ METODY V ACTIVE DIRECTORY Tento mechanismus je určitým mezistupněm mezi 1. a 2. verzí NTLM a někdy bývá označován jako NTLM++. Jedná se v podstatě o režim kompatibility NTLM v2, který lze použít když mezilehlá architektura tento protokol nepodporuje. Vychází z NTLM v1, přičemž do výpočtu odpovědi zakomponovává i výzvu klienta. Výzva klienta velikosti 8 bajtů je zhašována se stejně velkou výzvou serveru pomocí MD5. První část výsledného hashe pak tvoří vstup NTLM v1 mechanismu, kde je zpracována stejným způsobem, jako by je jednalo o samostatnou výzvu serveru. Výzvu klienta je ale nutné předat serveru, přičemž datová zpráva by měla být ve stejném formátu jako v případě běžného NTLM v1. Výzva klienta je tedy uložena na místo LM response, jelikož NTLM v1 je uzpůsoben pro zasílání LM i NTLM odpovědi. Protokol umožňuje využití výzvy serveru i klienta, čímž znesnadňuje útoky pomocí rainbow tables. Poskytuje tedy větší bezpečnost než samotný NTLM v1. LM verze 2 Stejně tak lze za určitý režim kompatibility NTLM v2 označit druhou verzi LM (dále LM v2). K výpočtu se zde také využívá klasický NTLM v2 hash hesla. Výzva serveru je spojena s 8-bajtovou výzvou klienta a zpracována pomocí HMAC-MD5 s NTLM v2 hashem jako klíčem. S tímto výsledkem je zřetězena výzva klienta a celek tak tvoří 24-bajtovou LM v2 odpověd. Takto vytvořená odpověd má pevnou délku a je možné ji přenést skrz architekturu, která podporuje pouze Lan Manager protokol. Zároveň je stále použit NTLM v2 hash a výzva klienta. Vzhledem k tomu, že protokol využívá HMAC-MD5, lze o označit za o něco lepší než NTLM++ [37]. 16

24 2. AUTENTIZAČNÍ METODY V ACTIVE DIRECTORY LM v.1 NTLM v.1 NTLM v.2 Kerberos Kvalita hesla 14 zn. ASCII 128 zn. Unicode 128 zn. Unicode 128 zn. Unicode (u strojů více) Hash hesla LAN Manager NTLM v.1 NTLM v.2 Typ autentizace výzva-odpověd výzva-odpověd výzva-odpověd důvěryhodná 3. strana Vzájemná autentizace ne ne ne ano Výzva klienta ne ne ano Výzva serveru ano ano ano Algoritmus odpovědi DES ECB DES ECB HMAC-MD5 AES (povinný), další dobrovolné Klíč odpovědi 56bit+56bit+16bit 56bit+56bit+16bit 128bit dle algoritmu Podpora SSO uložení pověření uložení pověření uložení pověření nativní Poprvé uveden MS LAN Manager MS Windows NT MS Windows NT 4.0 SP4 MS Windows 2000 Tabulka 2.1: Stručné srovnání vybraných autentizačních mechanismů 17

25 2.2.4 NTLM a zabezpečení přenosu 2. AUTENTIZAČNÍ METODY V ACTIVE DIRECTORY Jak bylo zmíněno dříve, samotné protokoly typu NTLM nezaručují zabezpečení přenosu dat. To je hlavní problém, který způsobuje náchylnost k man-in-the-middle útokům. Protokol se tak stává závislý na bezpečnosti přenosového kanálu vytvářeného aplikací, která ho využívá, a bezpečnostní přínos samotných autentizačních zpráv se snižuje. NTLM SSP Při implementaci protokolu jako modulu SSP poskytuje tento modul aplikaci podporu pro integritu (tzv. signing) a důvěrnost (tzv. sealing) zpráv prostřednictvím SSPI. Podporu obou funkcí mohou protistrany dohodnout během autentizace a potřebné klíče jsou v tomto případě odvozeny z autentizačních zpráv. Odpovědnost za jejich správné použití leží ale na aplikaci. Lze rozlišit dvě verze tohoto mechanismu zabezpečení relace. Základní, označovanou také NTLM1, a rozšířenou, označovanou jako NTLM2. V případě NTLM1 jde o původní verzi zabezpečeného kanálu NTLM SSP. U tohoto mechanismu je možné odvodit klíče z hashe hesla klienta, nebo pomocí příznaku vyžádat odvození klíče z LMv1 odpovědi. V druhém případě se pak klíč mění vždy při provedení autentizace. U NTLM1 byly z právních důvodů omezeny délky klíčů na 40, resp. 56 bitů. Pro integritu (signing) zpráv je pomocí RC4 šifrován CRC32 kontrolní součet zpráv. Při dohodnutí důvěry (sealing) je taktéž použita RC4 a je vždy použito i zajištění integrity. NTLM2, neboli rozšířené zabezpečení relace, je novější verze, která je použita podporují-li ji obě strany. Hlavní klíč je zde vždy odvozen z hesla klienta a z něj jsou dále vygenerovány 4 klíče. Pro integritu a důvěru, a to pro oba směry. Také přibyla možnost použít plnou délku klíče, tj. 128 bitů. Proces zajištění důvěry zůstal beze změny, naopak při výpočtu kontrolní hodnoty integrity je použit algoritmus HMAC-MD5 [21]. Extended protection Jedním z mechanismů pro zamezení man-in-the-middle útoku při použití IWA je i Extended protection. Tento mechanismus slouží pro svázání autentizační NTLM relace se službou a s použitým TLS kanálem a vychází z RFC5056 [39]. Svázání se službou provede klient tak, že sdělí serveru SPN požadované služby při zajištění integrity této informace. Svázání s TLS kanálem pak klient provede zasláním Channel Binding Token, přičemž je také nutné zajistit jeho integritu. Tento prvek lze použít jen v případě přenosu 18

26 2. AUTENTIZAČNÍ METODY V ACTIVE DIRECTORY za použití TLS a cílem je zabránit, aby útočník vytvořil jeden TLS kanál pro komunikaci s klientem a druhý se serverem a nepozorovaně přeposílal autentizační zprávy. Server pochopitelně musí přijaté informace o službě a kanálu správně ověřit [5] Single sign-on za použití NTLM Z předchozího popisu NTLM protokolů je zřejmé, že tyto protokoly samy o sobě nepodporují princip single sign-on. Při popisu Kerbera jsem zmínil princip dvou vrstev, které tuto vlastnost umožňovaly. Architektura NTLM a challenge-response protokolů obecně je ale v tomto ohledu pouze jednoúrovňová. Single sign-on je zde tedy nutné zajistit jiným způsobem. Ve všech zmíněných NTLM protokolech se pro autentizaci používá hash hesla a po jeho získání již heslo není dále třeba. Řešením je tedy mechanismus pro uložení vytvořeného hashe. Při přihlášení je tedy hash hesla uložen v paměti stroje stejným způsobem jako lístky systému Kerberos. Hash je pak na úrovni TGT, přičemž autentizace probíhá automaticky, a uživatel není znovu žádán o heslo. Zde je třeba si uvědomit zásadní rozdíly vůči architektuře Kerbera. Na rozdíl od hashe TGT nijak nezávisí na tajném hesle uživatele. Žádným způsobem tedy nelze z TGT heslo uživatele získat ani odhadnout. Dále má každý lístek omezenou platnost a možnost použití, NTLM hash ale zůstává neměnný a použitelný až do změny hesla. Před nedostatky NTLM, které spočívají v náchylnosti k man-in-themiddle útoku, varuje v jeho specifikaci [10] i samotný Microsoft. Dále byly jeho zranitelnosti prezentovány v různé podobě na bezpečnostních konferencích, např. [18, 22, 32]. Reakce a opravy byly schopné konkrétním útokům zabránit, takže použití NTLM nemusí vždy nutně znamenat akutní riziko. Jedná se ale o nekoncepční řešení, přičemž koncepčním by bylo opuštění tohoto protokolu ve prospěch například Kerbera. NTLM obecně nelze doporučit Další problematickou vlastností NTLM je fakt, že cílové zdroje či služby jsou identifikovány pomocí IP adresy. To může způsobit problém například pokud jsou cílové služby nasazeny na virtuálních strojích, tedy za NAT, přičemž s touto situací se potýkali i ve firmě TNS. Na druhou stranu Kerberos využívá pro identifikaci SPN a je tedy závislý na DNS, což může být v této konkrétní situaci výhodou. Ale i použití Kerbera za NAT může být problematické. Podobná situace byla diskutována zde [19], přičemž uvažovaný případ se od zmíněného použití virtuálních strojů mírně liší. 19

27 3 Použití autentizačních mechanismů 3.1 GSS-API Pokud vytváříme aplikaci, která provádí nějaký druh komunikace, je přirozeným požadavkem použití bezpečnostního mechanismu. Vyvíjet vlastní mechanismus je většinou velmi nevhodné a zpravidla se využije již existující. Vhodných mechanismů může být více a i API jejich implementací se mohou lišit, jak lze vidět u Kerbera V5 1. Vyvíjená aplikace je pak vázaná na konkrétní API, se kterým se vývojář musí dostatečně seznámit. Kromě nároků na dodatečné znalosti může vzniknout problém při změně implementace nebo při přechodu na jiný mechanismus. Takové změny potom vyžadují netriviální úpravy. Tuto situaci pomáhá řešit Generic Security Service API [28] (dále GSS-API), které je zároveň standardem IETF 2. To poskytuje jednotnou sadu funkcí pro různé bezpečnostní mechanismy. Aplikaci a tedy i jejího vývojáře tím stíní od konkrétního bezpečnostního mechanismu, kterým může být například Kerberos, NTLM nebo TSL/SSL [37]. Komunikující strany se v dokumentech GSS-API označují jako iniciátor a akceptor. Přičemž iniciátor zahajuje komunikaci a autentizuje se jako první. Kromě označení stran se v popisu používají další pojmy, které je vhodné zde zmínit: Pověření (credentials) je soubor informací, které patří určité entitě a ta se jimi může prokazovat. V GSS-API se využívají pro ustavení bezpečnostního kontextu mezi komunikujícími stranami. Mají formu datové struktury, která může obsahovat více položek specifických pro jednotlivé mechanismy. Typicky se jedná o nějaká tajemství jako např. klíče uložené v datové struktuře. Jedna struktura může sloužit jak pro vytváření bezpečnostního kontextu, tak pro ověřování kontextu protistrany. Tokeny jsou zprávy přenášené mezí komunikujícími instancemi GSS-API. Lze je rozdělit podle typu přenášeného obsahu na context-level a per-message tokeny. Jejich obsah je v režii GSS-API a je strukturován 1. Dvě nejvýznamnější open source implementace Kerbera, tj. Heimdal a verze od MIT, poskytují aplikaci odlišné funkce. Je-li taková implementace použita přímo bez GSS-API, může být přechod na jinou implementaci značně problematický. 2. Internet Engineering Task Force je otevřená organizace zabývající se vytvářením standardů v oblasti Internetu. Taktéž spravuje vydávání dokumentů Request for Comments (dále RFC). 20

28 3. POUŽITÍ AUTENTIZAČNÍCH MECHANISMŮ pomocí ASN.1 3. Samotná aplikace do tokenu nevidí a zajišt uje jen jeho přepravu protistraně. Obsah tokenů závisí z velké části na použitém bezpečnostním mechanismu. Komunikace mezi účastníkem, který používá GSS-API a účastníkem, který používá stejný mechanismus, ale v původní implementaci, tedy nemusí být možná. Context-level token je využíván na začátku komunikace pro ustavení bezpečnostního kontextu (viz dále). Jsou vytvářeny na základě pověření a předávány protistraně. Takový token může obsahovat i informaci o chybě, která nastala například při generování kontextu. Jako per-message tokeny jsou označovány datové zprávy, které využívají již ustaveného kontextu. Na rozdíl od předchozího typu se předávají jen v případě úspěšně vytvořené zprávy. Slouží k zabezpečení přenášených dat. Bezpečnostní kontext (security context) obsahuje informace o stavu komunikace. Je vytvářen na základě pověření a umožňuje použití bezpečnostních prvků zvoleného mechanismu. Vztahuje se pouze k bezpečnostní stránce přenosu a není tedy závislý na konkrétním transportním protokolu. Z bezpečnostních důvodů je ale možné kontext explicitně svázat s komunikačním kanálem, tedy provézt tzv. channel binding. V rámci ustavení kontextu se iniciátor komunikace autentizuje protistraně zasláním příslušného tokenu. Autentizace může být i oboustranná. Mechanismem se označuje skutečný bezpečnostní protokol, který zajišt uje požadované funkce. V tomto ohledu je GSS-API pouze zprostředkovatel jeho služeb. Zde je dobré zmínit, že bezpečnostní protokol může mít i více implementací, kdy každá je zde považována za samostatný mechanismus. GSS-API garantuje úspěšné ustavení kontextu a komunikaci jen pokud obě strany zvolí stejný mechanismus. Existují protokoly, které umožňují dohodnutí společného mechanismu účastníků, což samotné GSS-API neprovádí. Prvním protokolem, který poskytoval GSS-API byl Kerberos a ten také stále patří mezi nejvýznamnější GSS-API mechanismy. 3. Abstract Syntax Notation One je standard pro zápis struktury dat v abstraktní notaci. 21

29 3. POUŽITÍ AUTENTIZAČNÍCH MECHANISMŮ Použití GSS-API Typický postup volání GSS-API funkcí lze zjednodušeně rozdělit do 3 fází: Aplikace musí mít pro vytvoření spojení k dispozici pověření pro příslušné mechanismy. První fáze tedy spočívá v jejich získání a uložení do datové struktury. Na straně iniciátora se typicky pověření získávají automaticky např. při přihlášení uživatele. Pokud chceme využít jinou identitu nebo nastavit další parametry, lze o ně požádat explicitně voláním příslušné funkce (GSS_Acquire_cred()). To se také využívá na straně akceptora, který potřebuje data pro ověření iniciátora. V druhé fázi musí mezi sebou protistrany ustavit bezpečnostní kontext pomocí context-level tokenů. Ty jsou na straně iniciátora vytvářeny voláním GSS_Init_sec_context() pro konkrétní mechanismus. Akceptující strana je příjme a zpracuje pomocí GSS_Accept_sec_context(). Zároveň může voláním téže funkce vytvořit odpovědní token. Zasláním takového tokenu zpět iniciátorovi pak realizuje oboustrannou autentizaci. Počet přenesených tokenů, které jsou třeba pro ustavení kontextu závisí na použitém mechanismu. Jde-li o typ challenge-response, bude jich pochopitelně více, ale kontext lze ustavit i za použití 1 tokenu, resp. 2 pro vzájemnou autentizaci. V prvním context-level tokenu může iniciátor nastavit některé volitelné parametry spojení. Jedná se například o možnost delegace oprávnění protistraně, požadavek na vzájemnou autentizaci, ochranu přenášených zpráv (integrita i důvěrnost), anonymní autentizaci aj. Tato volitelné prvky ale nemusí být vždy podporovány. Pokud bylo úspěšně navázáno spojení, lze přistoupit k výměně zpráv v podobě per-message tokenů a tedy třetí fázi. Jejich ochrana závisí na použitém mechanismu a zvolených parametrech ale i na použitých funkcích. Je možné využít 2 páry funkcí: GSS_GetMIC()/GSS_VerifyMIC() a GSS_Wrap()/GSS_Unwrap(). První dvojice z nich poskytuje kontrolu autenticity a integrity zpráv přidáváním kontrolních hodnot. Druhá pak umožňuje navíc ochranu důvěrnosti zpráv Security Support Provider Interface Podobnou funkci jako GSS-API plní Security Support Provider Interface (dále SSPI). Tyto mechanismy jsou dokonce natolik podobné, že v některých případech mohou i spolupracovat. Jde o prvek operačního systému vyvinutý 22

30 3. POUŽITÍ AUTENTIZAČNÍCH MECHANISMŮ společností Microsoft. Taktéž poskytuje společné rozhraní pro použití bezpečnostních mechanismů, zde nazývaných Security Support Provider (dále SSP). Mezi tyto balíčky patří NTLMSSP, Kerberos SSP, Negotiate SSP a další. Použití SSPI je obdobné jako u GSS-API. Jsou zde k dispozici funkce na získání pověření, ustavení kontextu mezi stranami a vytváření a příjímání zabezpečených zpráv. Zprávy lze šifrovat (SSPI sealing) nebo pouze přidávat záznam pro kontrolu integrity (SSPI signing) [37]. 3.2 SPNEGO Ustavení kontextu a navázání spojení za použití GSS-API je možné jen pokud obě strany zvolí stejný mechanismus. Přitom je běžné, že aplikace účastníka může vybírat z více mechanismů, které podporuje a má k ním zároveň příslušná pověření (credentials). V této situaci je třeba, aby se obě strany shodly na podporovaném mechanismu. Samotné GSS-API tento proces výběru neřeší a ponechává prostor pro jeho samostatnou specifikaci. Tou je Simple and Protected GSSAPI Negotiation Mechanism (dále SP- NEGO). Jde o specifický mechanismus, který slouží pouze pro výběr onoho společného bezpečnostního GSS-API mechanismu. Až takto vybraný, skutečný, mechanismus poskytuje bezpečnostní funkce Použití SPNEGO Použití SPNEGO probíhá z pohledu aplikace stejně jako v rámci klasického schématu ustavení bezpečnostního kontextu GSS-API pro ostatní mechanismy, přičemž iniciátor zvolí jako mechanismus právě SPNEGO. Získaný token pro akceptora pak obsahuje místo autentizačních dat seznam mechanismů, které má iniciátor k dispozici. Seznam je seřazený dle jeho preferencí, které závisí na jeho lokální politice. Akceptor takovou zprávu příjme stejným způsobem jako jiný contextlevel token. Zpracuje ho ale pomocí SPNEGO a to tak, že ze seznamu vybere vyhovující mechanismus a výsledek oznámí iniciátorovi. Pokud akceptor SPNEGO nepodporuje nebo nemůže použít žádný z navržených mechanismů, ustavení bezpečnostního kontextu selže. V případě dohody dochází k ustavení bezpečnostního kontextu. To už závisí na zvoleném mechanismu, ale zprávy jsou stále přenášeny prostřednictvím SPNEGO tokenů. Až po ustavení kontextu ukončí SP- NEGO svoji činnost a předá kontrolu nad přenosem samotnému GSS-API mechanismu [27]. 23