Analýza SASL, část třetí

Po předchozích dílech, zaměřených hlavně na ověření klienta vůči serveru je cílem tohoto dílu zaměřit se na jednotlivé technologie sloužící pro volbu metody ověření a na metody zajišťující ověření vůči třetí straně. Ke každému protokolu budou opět zmiňovány jeho vlastnosti a struktura ochranných mechanismů. Cílem je poskytnout materiál, ze kterého je možné vycházet v případě analýzy použitých technologií. Pro návrat na předchozí díl je možné využít odkaz Analýza SASL, druhý díl

Úvodní terminologie pro GS2-*, GSSAPI, GSS-SPNEGO, SPNEGO, NEGOEXT

Jak už bylo zmíněno v prvním díle, uvedené protokoly zajišťují výběry nebo volání dalších mechanismů skrze vnitřní mechanismy. Pro osvětlení jak přesně pracují je nutné vysvětlit historii vývoje SASL mechanismu a vývoje ověřování uživatelů v operačních systémech.
GSSAPI: Úspěšnost a bezpečnost protokolu Kerberos vyvolala potřebu univerzálního rozhraní. Protože se od sebe jednotlivé implementace někdy i výrazně lišily, vzniklo za účelem standardizace rozhraní GSSAPI, standardizováno bylo ale až v roce 1993 (RFC 1508). Tedy rozhraní GSSAPI slouží primárně pro protokol Kerberos, přestože časem přibyla možnost volat další autentizační mechanismy. Jeho ekvivalentem je v prostředí operačních systémů společnosti Microsoft rozhraní SSPI, které ale s GSSAPI není zcela kompatibilní. Pokud se kombinuje volání z prostředí SSPI proti GSSAPI, je nutné v rámci komunikace explicitně specifikovat chybějící informace, jinak nemusí k ověření vůbec dojít. Jedná se tak o jakousi šedou zónu, na kterou dopadají rozdíly v implementaci. GSSAPI bylo zakomponováno už v základním SASL standardu, dnes neoficiálně nazývaném SASL1. Jedná se tedy o rozhraní, které z historických důvodů může být nabízeno jako metoda, což vede k chaosu a zmatkům.
SPNEGO: V prostředí operačních systémů Microsoft vznikl požadavek na možnost využití mechanismu Kerberos nebo NTLM na základě systémových možností a požadavků. Uvedený požadavek vedl k rozhraní SPNEGO, které dovolilo při autentizaci uživatele požádat o využití dostupné služby. Tuto službu vybíral server na základě poskytnutých informací od klienta a dostupných metod na své straně. Tento mechanismus dovoluje volat metody jako je Kerberos Network Authentication Service (RFC 4120, jak pro SASL tak prostředí Microsoft Windows), User to User Kerberos Authentication (pouze Microsoft Windows), Extended GSSAPI Negotiating mechanism NEGOEXT (OID 1.3.6.1.4.1.311.2.2.30, pouze Microsoft Windows), NT LanMager authentication protocol, známý jako NTLM (jak pro SASL, tak prostředí Microsoft Windows) a DIGEST-MD5 (pouze SASL). Ke standardizaci došlo v roce 1998 (RFC 2478), podpora pro tento mechanismus se objevila i v pozdějších verzích SASL. Z uvedeného důvodu zároveň vznikl další chaos v pojmenováních a možnostech vzájemného volání uvedených metod.
GSS-SPNEGO: Obecné rozhraní SPNEGO dostupné přes GSS-API.
GS2: Rozhraní GS2, přesněji GS2-[metoda] vzniklo o několik let později, jako součást SASL mechanismu. Primárním účelem byla standardizovaná metoda pro přístup ke GSSAPI, která byla následně rozšířena o možnost volání dalších podporovaných metod integrovaných v SASL. Přesněji, jednalo se jeho verzi s neoficiálním názvem SASL2, který měl výrazně změněnou architekturu za účelem snadnější rozšiřitelnosti. Přes podporu dalších mechanismů zůstává v GS2 hlavní podporovanou metodou Kerberos (GS2-KRB5). V případě GS2 se tedy jedná o metodu, která má za úkol využít GSSAPI pro volání konkrétních autentizačních mechanismů.
NEGOEXT: Jedná se o jeden z proprietárních mechanismů společnosti Microsoft v rámci GSSAPI rozhraní. Mechanismus je založen na SPNEGO, ale není standardizován. Dále rozšiřuje možnost volání autentizačních procedur mimo běžného NTLM a Kerberos5 o takové mechanismy, jakými jsou OAUTH, OpenID a další, určené pro federované identity. Příkladem mohou být ověření proti cloudovým systémům jako je Azure. NEGOEXT je možné identifikovat dle (OID 1.3.6.1.4.1.311.2.2.30). NEGOEXT je tedy rozšíření mechanismů SPNEGO.

SPNEGO a SPNEGO-PLUS

V tomto konkrétním případě je diskutabilní, zda algoritmus hodnotit jako autentizační algoritmus, nebo mechanismus dovolující volbu mezi protokoly Kerberos Network Authentication Service (RFC 4120), User to User Kerberos Authentication (pouze Microsoft Windows), Extended GSSAPI Negotiating mechanism NEGOEXT (OID 1.3.6.1.4.1.311.2.2.30), NT LanMager authentication protocol, známý jako NTLM a DIGEST-MD5 (pouze SASL). Pro volání se zpravidla využívá GSSAPI, v případě prostředí Microsoft Windows je možné použít s výhradami ještě rozhraní SSPI (API pro SPNEGO a další mechanismy, rozdíly a vztahy již zmíněny v prvním díle).
V průběhu ověřování klient posílá seznam podporovaných mechanismů na server a server volí metodu přihlašování. Veškeré výměny informací probíhají přes mechanismus SPNEGO až do ukončení výběru, následně pokračuje komunikace přímo se zvoleným autentizačním mechanismem. Pro rozšířenou metodu SPNEGO-PLUS verzi platí opět pravidlo, že uvedený algoritmus je pomocí kryptoprimitiv vázán na konkrétní komunikační kanál (tedy SPNEGO-PLUS vyžaduje informace o komunikačním kanále a poskytuje vazbu komunikačního kanálu na dané přihlášení). Zajímavostí je vlastnost SSPI, která není zcela kompatibiliní s GSSAPI a v tomto případě je nutné mechanismy odpovídajícím způsobem informovat, aby bylo možné ověření vůbec dokončit. Přes toto rozhraní je možné využít pouze metodu SPNEGO, nikoliv SPNEGO-PLUS. Dále, přestože SPNEGO podporuje technologii SSO (Single-Sing On), je potřeba zabránit možnosti ověření přes NTLM nebo DIGEST-MD5 a podporovat pouze bezpečné metody (Kerberos). Uvedený způsob přihlašování je určen hlavně pro systémy využívající protokol SMB (Samba) a pro ověření přístupu k webovým serverům, odpovídá specifikaci v rámci RFC 4178.

Channel Binding: Pouze pro PLUS verzi.
Realms: Ano
Kryptoprimitiva: Zastaralé (NTLM a Kerberos), aktuální (Kerberos)
Počet stran při autentizaci: 2 pro NTLM, 3 pro Kerberos
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Za určitých podmínek
Tokenizace: N
Jedinečnost: N/A
Ochrana credentials: N/A
Ochrana proti Replay: N/A
Ochrana proti Relay: N/A
Ochrana proti Hijack: N/A
Ochrana proti Forge: N/A
Podpora MFA: N/A
Ochrana integrity: N/A
Typ šifrování: N/A

GS2-*, GSSAPI, GSS-*

Rozhraní GSSAPI umožňuje přístup k velkémnu množství různých autentizačních mechanismu, GS2 je mechanismus schopný volat uvedené API v rámci SASL. Mechanismy GSS-* jsou pak vlastní mechanismy volatelné přímo přes API.

Channel Binding: Pouze pro PLUS verzi.
Realms: Ano
Kryptoprimitiva: Zastaralé (NTLM a Kerberos), aktuální (Kerberos)
Počet stran při autentizaci: 2 pro NTLM, 3 pro Kerberos
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Za určitých podmínek
Tokenizace: Možná
Jedinečnost: N/A
Ochrana credentials: N/A
Ochrana proti Replay: N/A
Ochrana proti Relay: N/A
Ochrana proti Hijack: N/A
Ochrana proti Forge: N/A
Podpora MFA: N/A
Ochrana integrity: N/A
Typ šifrování: N/A

GS2-KRB5, GS2-KRB5-PLUS

Jedná se o metodu ze skupiny GS2 (GSS SASL), poskytovanou skrze GSS-API. Více o GS2-KRB5 v části KERBEROS_V5, metoda GS2-KRB5-PLUS obsahuje navíc vazbu na kanál přenášející informace. Příkladem může být SSL/TLS. Více o této metodě opět v části KERBEROS_V5.

KERBEROS_V4

V roce 1983 vznikla na MIT (Massachusetts Institute of Technology) ve spolupráci se společnostmi DEC a IBM projekt Athena. Jeho cílem bylo vytvořit nástroj pro sítě na této univerzitě. Kerberos byl nástroj zajišťující ověřování a byl jedním z nástrojů v rámci tohoto projektu. Vzhledem k povaze protokolu, který dovolil uživatelům se pomoci centrálních systémů ověřovat, bylo nutné přistoupit k tomuto procesu jinak než u běžných systémů a chránit tak uživatelská tajemství před odposlechem a zneužitím. První verze protokolu Kerberos se datuje ještě před projekt Athena, ani první ani druhá verze nikdy nebyla veřejně dostupná. Třetí verze vznikla v roce 1988 a až teprve čtvrtá verze získala pozornost. Od této doby se tok komunikačních zpráv již nezměnil, tedy toky dat jsou shodné jak pro Kerberos v4, tak pro Kerberos v5. Hlavními autory byly Steve Miller a Clifford Neumann, spolu s nimi ovšem na protokolu pracovali další spolupracovníci z uvedeného projektu.
Kerberos v4 používá pevně danou strukturu zpráv, service ticket má velikost 256B a tedy není možné ho libovolně rozšiřovat. Tato struktura samozřejmě výrazně omezuje použitelnost, není možné s pomocí uvedeného protokolu transportovat rozšiřující údaje vztažené k uživateli. Stejně tak používal jedinou časovou zónu a nebyl schopen pracovat mezi časovými pásmy, pro šifrování se používal pouze algoritmus DES. První verze protokolu Kerberos navíc byly zatíženy exportními omezeními, tedy byl použit DES se 40b klíčem. Z uvedeného důvodu vznikly dvě další implementace, vytvořené mimo území USA, které neměla uvedená omezení.
Popis protokolu je v dalším odstavci u Kerberos v5. Pro šifrování se zpravidla používal algoritmus DES v CBC módu, který nebylo možné měnit. Pro některé informace se používalo šifrování pomocí DES-ECB, nebo DES-PCBC, pro kontrolu kryptogramů se používal jednoduchý kryptografický kontrolní součet založený na DES-CBC. Všechny zprávy byly opatřeny kontrolním součtem využívajícím CRC-32.

Channel Binding: Ne
Realms: Ano
Kryptoprimitiva: Zastaralé (DES)
Počet stran při autentizaci: 3 pro Kerberos
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Ne
Tokenizace: Ano
Jedinečnost: N/A
Ochrana credentials: Ano
Ochrana proti Replay: Ano
Ochrana proti Relay: N/A
Ochrana proti Hijack: N/A
Ochrana proti Forge: N/A
Podpora MFA: N/A
Ochrana integrity: N/A
Typ šifrování: Interní

KERBEROS_V5

V roce 1993 pokračoval vývoj projektu Kerberos další verzí. Došlo k přepracování protokolu, začala být používána dynamická struktura. Nová verze začala podporovat časové zóny, což řešilo původní problémy s přihlašováním. Dále, předchozí verze měla přesně určenou strukturu protokolu, ale nová verze začala pro data používat dynamickou strukturu založenou na struktuře ASN.1 a formátu DER. Tyto zkratky je možné najít i u certifikátů. ASN.1 je symbolický jazyk popisující strukturu dat, DER je formát kódování zajišťující jednoznačně nejkratší možnou délku dat. To je výhodné v případě jakéhokoliv digitálního podpisu, protože data jsou jednoznačně uspořádaná. Navíc vlastní struktura díky struktuře ASN.1 dovoluje přenášet data, která nebyla součástí návrhu. Příkladem jsou autorizační informace v rámci Microsoft Active Directory, kde service ticket obsahuje seznam příslušnosti ke skupinám PAC (Priviledge Attribute Certificate). Ten má samozřejmě také svá omezení, pro Kerberos protokol jsou spíše technického ražení. V prostředí sítí Microsoft Windows jsou omezení vázaná na maximální velikost PAC záznamu, který je pro jednotlivé verze následující:
- Windows 2000 a další - 8KB
- Windows 2003 a další - 12KB
- Windows 2008 a další - 48KB
- Windows 2012 a další - 64KB, hodnotu je možné konfiguračně změnit
Více o protokolu Kerberos a zvláště o implementaci v prostředí Microsoft Windows lze najít v článku Autentizace ke sdíleným složkám využívající protokol SMB

Rozpis vyměňovaných zpráv:

• S1: AS REQUEST, součást dotazu klienta na AS.
         IDClient||TimestampClient||NonceClient
• R2: AS REPLY, součást odpovědi AS.
         KKTS=Enc(KClient,KKTS)
• R3: AS REPLY, součást odpovědi AS.
         TGT=Enc(KTGS,IDClient||KClient||Lifetime||..)
• S4: TGS REQUEST, součást zprávy na TGS.
         Enc(KTGS, TGT) - kopie šifrovaného TGT ticketu z předchozího kroku
• S5: TGS REQUEST, součást zprávy na TGS.
         Enc(KTS, IDClient||Timestamp||..)||IDServer||NonceClient
• R6: TGS REPLY, součást odpovědi TGS.
         Enc(KAP, KSS)
• R7: TGS REPLY, součást odpovědi TGS.
         Enc(KTS, IDClient||KSS||Lifetime||..)
• S8: AP REQUEST, součást zprávy na aplikační server.
         Enc(KAP, KSS) - kopie Session klíče z předchozího kroku
• S9: AP REQUEST, součást zprávy na aplikační server.
         Enc(KSS, IDClient||Timestamp)
• R10: AP REPLY, součást odpovědi aplikačního serveru. K této odpovědi dochází pouze v případě oboustranné autentizace (mutual authentication)
         Enc(KSS, TimestapmServer)
• S10: PAC VALIDATION REQUEST, součást volitelného ověření klienta aplikačním serverem na TGS. Zpravidla se nepoužívá.
         Enc(KAP, PAC Signature||PAC Info||TGT||Timestamp)
• R11: PAC VALIDATION RESPONSE, součást volitelné odpovědi TGS na aplikačním server. Zpravidla se nepoužívá.
         Enc(KAP, Validated PAC Signature||Validated PAC Attributes||Timestamp)

Channel Binding: Ne
Realms: Ano
Kryptoprimitiva: Zastaralé (DES)
Počet stran při autentizaci: 3 pro Kerberos
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Ne
Tokenizace: Ano
Jedinečnost: N/A
Ochrana credentials: Ano
Ochrana proti Replay: Ano
Ochrana proti Relay: N/A
Ochrana proti Hijack: N/A
Ochrana proti Forge: N/A
Podpora MFA: N/A
Ochrana integrity: N/A
Typ šifrování: Interní

OAUTH10A

Původní protokol OAUTH vznikl jako kombinace existujících protokolů a praktik pro delegaci oprávnění. Nejedná se tedy o autentizační, nýbrž o autorizační protokol. V rámci IETF byla v roce 2007 založena pracovní skupina s cílem tento protokol standardizovat a v roce 2007 došlo k publikaci prvního standardu. Na základě zranitelnosti (session fixation) publikované v roce 2009 vznikla revize, označovaná jako OAUTH10A. Tento protokol podporuje delegaci oprávnění, ale pouze v rámci jednoho identity providera. Nepodporuje sdílení tokenů a centralizovanou správu více domén.
Jedná se o mechanismus, dovolující ověření klienta a delegování oprávnění (např. na aplikaci třetí strany) s minimálním nasazením kryptografie. Vlastní protokol používá pro tvorbu kontrolního součtu buď digitální podpis založený na RSA nebo pouze HMAC, tato forma "podpisu" musí být součástí všech volání API. Jiná forma kryptografické ochrany použita není. Součástí komunikace jsou následující komponenty:
- uživatel, tedy vlastník dat
- autentizační server pro přihlášení, v tomto případě zároveň autorizační server pro delegaci oprávnění
- aplikace nebo aplikační server, žádající o oprávnění. V této verzi se považuje za vlastníka zdrojů

S1: Před jakýmikoliv požadavky se klient musí přihlásit na autentizačním serveru. V tomto případě je autentizační a autorizační server shodný, po přihlášení poskytuje autorizační data umožňující delegování oprávnění. Vlastní přihlašovací metoda není v protokolu OAUTH10A specifikována, nejčastěji jsou přihlašovací údaje chráněny pouze pomocí transportního šifrování (HTTPS, tedy HTTP s podporou SSL/TLS). Při přihlášení za účelem registrace se consumer key, který je veřejný a slouží pro další identifikaci po dobu spojení. Při dalších přihlašováních se consumer key již jenom využívá.
Na začátku spojení požádá klient o dočasný request token pomocí dotazu, kde využívá HTTPS protokol. Ten je zvolen z důvodu ochrany před odposlechem. Protože se přenášené informace o účtu jinak nechrání, je vhodné využít pro spojení s autentizačním serverem jakýkoliv jiný algoritmus, než je PLAIN nebo LOGIN. Obsah HTTP requestu vypadá přibližně tímto způsobem, veškeré další výměny informací využívají podobné záznamy:
- oauth_consumer_key="consumer key",
- oauth_signature_method="PLAINTEXT|HMAC-SHA1|RSASSA-PKCS1-v1_5",
- oauth_signature="signature based on oauth_signature_method algorithm",
- oauth_timestamp="timestamp",
- oauth_nonce="nonce",
- oauth_callback="https address to receive token"
Kde:
- Signature=HMAC-SHA1(Consumer||Token||&,HTTPREQ)
- HTTPREQ obsahuje HTTP parametry, metodu a URI pro spojení.

R2: Server vrátí dočasný token nebo dočasné přihlašovací údaje a adresu pro autorizaci (URI).
S3: Klient předá informace aplikaci nebo aplikačnímu serveru pro autorizaci (URI).
S4: Aplikační server využije adresu pro autorizaci (URI) k přihlášení pomocí dočasného tokenu.
R5: Server autorizuje nebo zamítne autorizaci aplikace nebo aplikačního serveru. V případě autorizace posílá verifikační klíč a přesměruje server na specifickou adresu (callback URI).
R6: Aplikační server předá verifikační klíč a novou adresu (callback URI).
S7: Klient posílá verifikační klíč, dočasný token a dočasné přihlašovací údaje serveru. Výměnou požaduje token pro aplikační server.
R8: Klient dostává token pro aplikační server.
S9: Klient předává token aplikačnímu serveru.

Channel Binding: Ano
Realms: Ne
Kryptoprimitiva: Zastaralé (SHA-1) nebo výběhové (RSA)
Počet stran při autentizaci: 3
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Možná
Tokenizace: Ano
Jedinečnost: N/A
Ochrana credentials: S výhradou
Ochrana proti Replay: Ano
Ochrana proti Relay: N/A
Ochrana proti Hijack: N/A
Ochrana proti Forge: N/A
Podpora MFA: Ano
Ochrana integrity: Ano (HMAC-SHA1)
Typ šifrování: TLS (vyžadováno)

XOAUTH

Protokol XOAUTH vznikl jako implementace autorizačního protokolu OAUTH společností Google (OAUTH → XOAUTH) s cílem podporovat aplikace a služby jako je GMail, kde je potřeba pro ověření uživatele předat jeho uživatelské jméno a heslo. Tato specifická implementace je určena pouze pro zabezpečení přihlášení k poštovním serverům (protokoly SMTP, IMAP4, POP3). Až na drobné detaily je shodný s OAUTH10A.

Channel Binding: Ano
Realms: Ne
Kryptoprimitiva: Zastaralé (SHA-1) nebo výběhové (RSA)
Počet stran při autentizaci: 3
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Možná
Tokenizace: Ano
Jedinečnost: N/A
Ochrana credentials: S výhradou
Ochrana proti Replay: Ano
Ochrana proti Relay: N/A
Ochrana proti Hijack: N/A
Ochrana proti Forge: N/A
Podpora MFA: Ano
Ochrana integrity: Ano (HMAC-SHA1)
Typ šifrování: TLS (vyžadováno)

Závěr

Tento přehled popisuje základní strukturu protokolů, používaných při ověřování uživatelů pomocí základních rozhraní a protokolů. Z celého seznamu zbývají už jen OAUTH2, XOAUTH2, OAUTHBEARER, OPENID20 a SAML. Tyto protokoly budou rozebírány v dalším díle SASL dil ctvrty. Poslední díl se následně bude věnovat implementacím v jednotlivých knihovnách a algoritmům, které je možné ze současného pohledu považovat za bezpečné.

Autor článku:

Jan Dušátko

Jan Dušátko se počítačům a počítačové bezpečnosti věnuje již skoro čtvrt století. V oblasti kryptografie spolupracoval s předními odborníky např. s Vlastimilem Klímou, či Tomášem Rosou. V tuto chvíli pracuje jako bezpečnostní konzultant, jeho hlavní náplní jsou témata související s kryptografií, bezpečností, e-mailovou komunikací a linuxovými systémy.