Kerberos část 4 - hlavní termíny Kerberos protokolu -> SAMURAJ-cz.com

Cryptography (kryptografie - šifrování)

Kerberos protokol je postaven na šifrování, proto si na začátku velmi stručně zmíníme hlavní termíny. Kryptografie se používá pro dosažení různých cílů. Jde o Confidentiality (důvěrnost, ochrana proti čtení dat), Data integrity (ochrana dat před změnou), Authentication (ověření, že data pochází od dané strany), Non-repudiation (neodmítnutelnost).

Encryption (šifrování) - transformace dat (plaintext) za účelem jejich zabezpečení (ciphertext), takže pouze ten, kdo zná klíč, je může rozšifrovat, existuje šifrování se symetrickým klíčem, kde je stejný klíč pro šifrování i dešifrování, a šifrování s veřejným klíčem, kde šifrovací klíč je veřejně známý, takže každý může data zašifrovat, ale dešifrovat je může pouze majitel privátního klíče, příklad šifer je SSL, PGP, AES, DES, 3DES
Hashing (hašování) - funkce, která z různě dlouhých vstupních dat vytváří kratší výstup pevné délky (hash), stejný vstup má vždy stejný hash, různé vstupy mají různý výstup, z výstupu nelze získat vstupní data, pokud dojde ke změně vstupu, tak se výrazně změní hash (využívá se pro zajištění integrity dat, kdy se k datům vytvoří kontrolní součet), příklad Hash funkcí MD5, SHA, SHA2
Encoding (kódování) - transformace dat do jiného formátu (aby se mohli lépe zpracovávat), proces je veřejně známý a může být obrácen

Key Distribution Center (KDC)

KDC je server, který autentizuje klienta a vystavuje tikety. Jde o centralizovanou důvěryhodnou třetí stranu v Kerberos komunikaci. U MS je součástí každého doménového řadiče (DC) a obsahuje dvě nezávislé služby (které se obě nachází na DC):

Authentication Service (AS) - provádí autentizaci uživatele a odesílá mu TGT
Ticket-Granting Service (TGS) - na základě TGT ověří uživatele a odesílá Service Ticket pro požadovanou službu

KDC přistupuje k Active Directory informacím o účtech, včetně hesel. Pro ověření se uživatelské heslo využívá pouze k získání TGT, a ani v této fázi se neposílá po síti, dále se již využívá TGT.

Secret Key - tajný klíč

Tajný klíč slouží k ověření uživatele pomocí šifrování/dešifrování komunikace, sdílí jej mezi sebou Principal (klient či služba) a KDC. Používá se několik označení, asi nejčastější je Secret Key, další je Shared Secret Key (sdílený tajný klíč) či obecně Encryption Key (šifrovací klíč). Secret Key vznikne z textového hesla, ke kterému se přidá sůl (Salt), což je Principal Name včetně Realmu (to zajistí, aby ani uživatelé se stejným heslem, neměli stejný klíč). Tento řetězec zpracuje funkce string-to-key (string2Key), která provede jednosměrnou hashovací funkci (nelze zpět získat heslo), a výsledkem je klíč.

Princip ověření je takový, že tajemství je známo pouze dvěma stranám (uživatel a KDC). Každá strana může ověřit tu druhou tak, že druhá strana zná stejné tajemství. Aby se ověřilo, že druhá strana zná tajemství, tak Kerberos využívá Secret Key Cryptography (šifrování pomocí klíče). Jedna strana zašifruje zprávu pomocí klíče, pokud ji druhá dokáže rozšifrovat, tak musí znát klíč (tajemství). Využívá se symetrické šifrování (stejný klíč dokáže data zašifrovat i rozšifrovat).

Termín Secret Key nejčastěji používáme pro klíč uživatele, ale šifrovacích klíčů se používá více:

Dlouhodobé symetrické klíče (Long-Term Symmetric Keys)

Vytváří se z hesla, textové heslo se pomocí šifrovací funkce (například DES-CBC-MD5) transformuje na klíč. Patří sem:

User key - k účtu uživatele, heslo je zadáno v AD a na stanici se zadá při přihlášení
System key - k účtu počítače, když se počítač zařadí do domény, tak dostane heslo, z něj se vytvoří klíč
Service key - služby získají klíč z hesla účtu, který používají pro přihlášení
Inter-realm keys - pro autentizaci mezi doménami (cross-realm authentication), kde je vytvořen vztah důvěry

Dlouhodobé asymetrické klíče (Long-Term Asymmetric Keys)

MS používá pouze v případě veřejného klíče pro autentizaci certifikátem z čipové karty (Smartcard).

Krátkodobé symetrické klíče (Short-Term Symmetric Keys)

Session Key pro šifrování komunikace mezi KDC a klientem nebo službou a klientem. KDC si jej neukládá, protože klient jej vždy pošle v šifrovaném tiketu.

Tiket (ticket)

Tiket představuje Kerberos credentials, jde o záznam (uložený v paměti či v souboru na disku), který může být použit pro ověření identity. Tickety jsou základem autentizace v Kerberosu, kdy se po síti neposílají hesla, ale pouze šifrované tickety. Obsahuje identitu klienta, Session Key, časovou známku a další informace. Šifruje se pomocí serverového Secret Key.

Pro žádost a doručení tiketů se používají Kerberos zprávy (pakety). V žádosti (request) se posílá požadovaná (podporovaná) šifrovací metoda a požadované vlastnosti (flags). Na klientovi se tikety ukládají do vyrovnávací paměti (volatile memory space, ne na disk), takže se mohou použít opakovaně. Mají určitou dobu platnosti. Používáme dva typy tiketů:

Ticket-Granting Ticket (TGT)

TGT je speciální Service Ticket pro službu KDC (krbtgt). Zařizuje bezpečné předání uživatelových credentials z AS na TGS. Můžeme říci, že slouží k autentizaci uživatele. Je šifrovaný pomocí KDC Secret Key (klient jej nemůže rozšifrovat). Obsahuje údaje o klientovi, příznaky (flags), časové razítko, případné další údaje a Session Key (při použití TGT nemusí KDC hledat Secret Key klienta, ale rozšifruje si Session Key a ten použije). Defaultní platnost je 10 hodin, ale může se provádět obnova (renew) bez potřeby zadat heslo. Microsoft rozšířil standardní tiket o autorizační data, takže je zde také SID uživatele a SIDy bezpečnostních skupin, kterých je členem.

Service Ticket

Zařídí, aby se uživatelova credentials bezpečně dostala z TGS ke službě. Slouží tedy k autentizaci uživatele u služby. Obsahuje nešifrovaně SPN služby a šifrovaně, pomocí Secret Key služby (takže klient nemůže rozšifrovat), údaje o klientovi (může zde být i adresa), dobu platnosti a Session Key pro komunikaci klienta a služby. Microsoft rozšířil standardní tiket (stejně jako TGT) o autorizační data, takže je zde také SID uživatele a SIDy bezpečnostních skupin, kterých je členem.

Níže je příklad Service Ticketu, jak si jej můžeme vypsat na klientovi.

C:\>klist
Current LogonId is 0:0x4c2b5
Cached Tickets: (10)
  
#2>  Client: bouska @ FIRMA.LOCAL
     Server: HTTP/www.firma.local @ FIRMA.LOCAL
     KrbTicket Encryption Type: RSADSI RC4-HMAC(NT)
     Ticket Flags 0x40a00000 -> forwardable renewable pre_authent
     Start Time: 4/25/2014 12:53:44 (local)
     End Time:   4/25/2014 22:18:52 (local)
     Renew Time: 5/2/2014 12:18:52 (local)
     Session Key Type: RSADSI RC4-HMAC(NT)
     Cache Flags: 0
     Kdc Called: dc.firma.local

Authenticator

Spolu s tiketem klient posílá i čerstvě generovaný Authenticator šifrovaný pomocí Session Key (ten je obsažen v tiketu). Služba může věřit, že tiket není podvržený, protože je šifrovaný jejím klíčem (který zná pouze KDC a ona). Nemá ale ověřeného odesílatele (protože vlastní tiket může být ukraden), proto se používá Authenticator.

Authenticator je šifrovaný klíčem (Session Key), který zná pouze správný klient a server. Obsahuje časovou známku, která se ověřuje, jestli není rovna nebo menší, než naposled přijatá časová známka od klienta (tím se zajistí, že authenticator není možno použít opakovaně). Také se kontroluje časová známka s časem na serveru a nesmí se lišit o víc než 5 minut (klient a server musí mít synchronizovaný čas). Dále obsahuje jméno a Realm klienta, kontrolní součet aplikačních dat a může zde být šifrovací klíč (který by se použil místo Session Key).

Pre-authentication

Použití před-autentizace zvyšuje bezpečnost přihlašovacího procesu. Při normálním průběhu klient žádá o TGT a v žádosti (KRG-AS-REQ) odesílá pouze svoje jméno a doménu. KDC nalezne uživatele a pomocí jeho Secret Key zašifruje Session Key, který mu pošle (spolu s TGT). Když klient nezná heslo (Secret Key), tak si nemůže rozšifrovat Session Key a tudíž dále komunikovat s KDC. Útočník by ale mohl poslat požadavek za jiného uživatele. A pak se pokusit provádět nějaké útoky hrubou silou na šifrovaný Session Key a tím by mohl zjistit heslo uživatele.

Proto se při Pre-authentication na požadavek KRG-AS-REQ odešle KRB-ERROR s hodnotou KRB5KDC_ERR_PREAUTH_REQUIRED. Na to klient odpoví novým KRG-AS-REQ paketem, kde do oblasti PADATA přidá časovou známku zašifrovanou pomocí uživatelova Secret Key. KDC rozšifruje časovou známku (tím ověřil uživatele) a ještě zkontroluje, jestli je čas v pořádku (stejně jako u Authenticator). Dále pokračuje běžným způsobem.

Pozn.: V Kerberos v5 je Pre-authentication volitelná, ale v Active Directory je defaultně vyžadována.

Realm - doména

Každá organizace, která chce provozovat Kerberos, si definuje svůj vlastní Realm. Jméno Realmu, v které je uživatel registrován, je součástí uživatelského jména. Může se navazovat vztah mezi Realmy, mohou být hierarchicky organizovány a nejčastěji se používá DNS zápis. V Microsoft prostředí je Kerberos Realm ekvivalentem pro Active Directory doménu. Kerberos Realm je závislý na velikosti znaků a standardně se používají velká písmena. KDC může vydávat tikety pouze pro svůj Realm. Příkladem Realmu je FIRMA.LOCAL.

Principal Name

Principal je unikátní identita (pojmenovaná entita klienta nebo serveru), které může Kerberos přiřadit tiket. Kerberos slouží k prokázání, že komunikující objekt byl u KDC registrován pod identitou, za kterou se vydává. Principal může mít řadu komponent, které se oddělují lomítkem /, ale nejčastější tvar je primary@REALM nebo primary/instance@REALM. Souvisí to s dříve popsanými UPN a SPN v Active Directory. Příkladem uživatelského Principal je bouska@FIRMA.LOCAL a Principal služby je HTTP/www.firma.local@FIRMA.LOCAL.

Pozn.: Principal se většinou používá včetně uvedení Realmu, ale není to podmínka.

Secure Channel

Je používán ve Windows, když se přenáší Secret Key (třeba když vytvoříme uživatele a zadáme jeho heslo), tak je přenos zabezpečen jiným Secret Key.

Kerberos zprávy (packety)

Kerberos protokol standardně komunikuje na TCP portu 88. Používá několik typů zpráv (Message Type), některé mohou být zabaleny v jiném protokolu. Podrobné informace o zprávách, tiketech, jejich obsahu a datových typech nalezneme ve specifikaci RFC 4120 - 5. Message Specifications.

Komunikace klienta s KDC

Nejčastější zprávy spočívají ve výměně požadavku (Request) a odpovědi (Reply). První komunikace je mezi klientem a Kerberos serverem (tedy KDC). Pro získání TGT se komunikuje s Authentication Service (AS) a posílá se KRB-AS-REQ (10) a KRB-AS-REP (11). Pro získání Service Ticket se komunikuje s Ticket-Granting Service (TGS) a posílá se KRB-TGS-REQ (12) a KRB-TGS-REP (13).

Následující obrázek ukazuje celou komunikaci zachycenou pomocí programu Wireshark. Jde o autentizaci k webové aplikaci a je vyžadována před-autentizace. Detaily se dozvíme v dalších dílech seriálu.

Wireshark - packety procesu Kerberos SSO

Když se podíváme na obsah zpráv, tak požadavky mají dvě hlavní části. padata, což je zkratka pre-authentication data, zde mohou být informace potřebné pro zpracování nebo dešifrování. Třeba u KRB-TGS-REQ je zde Authentication Header (Ticket-Granting Ticket a Authenticator). A KDC-REQ-BODY, kde jsou vlastní data požadavku, třeba Client Name, Realm, Server Name (SPN). Odpověď může mít více částí, je zde třeba Client Name, Client Realm a Ticket, což je vlastní vystavený Ticket, v něm vidíme Server Name (SPN), Realm a šifrovanou část.

KRB-AS-REQ - požadavek na získání TGT

KRB-AS-REP - vrácení TGT

KRB-TGS-REQ - požadavek na získání Service Ticket

KRB-TGS-REP - odpověď s Ticketem

Komunikace klienta se službou

Pro autentizaci uživatele k aplikačnímu serveru komunikuje klient a server. Posílá se KRB-AP-REQ (14), který obsahuje hlavně tiket (Service Ticket) a authenticator. V ap-options může být příznak mutual-required a pak musí server odpovědět zprávou KRB-AP-REP (15) čímž autentizuje sebe u klienta. Objevit se může také zpráva KRB-ERROR (30) s nějakou chybovou informací. Existuje ještě několik dalších typů zpráv, ale ty se používají pro speciální případy.

www.SAMURAJ-cz.com

Kategorie článků

Nástroje

Hledání

Články