Kerberos protokoll

Történet és fejlődés

Az MIT fejlesztette ki a Kerberost az Athena projekt által nyújtott hálózati szolgáltatások védelmére. A protokollt a görög mitológia Kerberosz (vagy Kerberosz) nevű karakteréről nevezték el, aki a görög mitológiában Hádész háromfejű, szörnyűséges házőrző kutyájaként ismert. A protokollnak több változata létezik; az 1-3. változatot csak az MIT-n belül használják.

Steve Miller és Clifford Neuman, a Kerberos 4. verziójának (amely a DES titkosítási algoritmust használta 56 bites kulcsokkal) elsődleges tervezői 1989-ben publikálták ezt a verziót, bár elsősorban az Athena projekthez szánták.

A John Kohl és Clifford Neuman által tervezett 5. verzió 1993-ban jelent meg RFC 1510-es számmal (amelyet 2005-ben az RFC 4120-as számmal elavulttá tettek), azzal a céllal, hogy a 4. verzió korlátait és biztonsági problémáit kiküszöbölje. Az MIT a BSD licenchez hasonló szoftverlicenc alapján szabadon hozzáférhetővé teszi a Kerberos 5. verziójának implementációját.

Számos vállalat használta a Kerberos 5. verzióját kereskedelmi szoftverekben, többek között:

·         A Microsoft Windows 2000 és újabb Windowsok a Kerberost használják alapértelmezett hitelesítési módszerként. A Kerberos protokollcsomag
néhány Microsoft-kiegészítése az RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols" című dokumentumban dokumentált. Az
RFC 4757 dokumentálja a Microsoft RC4 titkosításának használatát.
Bár a Microsoft használja a Kerberos protokollt, nem használja az MIT szoftverét[1].

·         Az Apple Mac OS X szintén a Kerberost használja mind az ügyfél-, mind a kiszolgálóverzióban.

·         A Red Hat Linux 4-es és újabb verziója a Kerberost használja mind az ügyfél-, mind a szerverváltozatban.

2005-ben az IETF Kerberos munkacsoportja új, frissített specifikációkat vezetett be a Kerberos 5. verziójához [2]:

·         "Titkosítási és ellenőrzőösszeg-specifikációk" (RFC 3961),

·         "Advanced EncryptionStandard (AES) Encryption for Kerberos 5" (RFC 3962),

·         A Kerberos 5. verziójának új kiadása: "The Kerberos Network Authentication Service (V5)" (RFC 4120). Ez a változat elavulttá teszi az RFC 1510-et, részletesebb és világosabb magyarázatban tisztázza a protokoll és a rendeltetésszerű használat szempontjait,

·         A GSS-API specifikáció új kiadása "A Kerberos 5. verziójú általános biztonsági szolgáltatási alkalmazási program-interfész (GSS-API) mechanizmusa: Verzió: 2. verzió." (RFC 4121).

2007-ben az MIT megalakította a Kerberos konzorciumot a fejlesztés folytatására.

Protokoll

A Kerberos a Needham-Schroeder protokollt használja alapjául. Megbízható harmadik fél hitelesítést használ, amelyet "kulcselosztó központnak (KDC)" neveznek, és amely két logikailag különálló részből áll: egy hitelesítési kiszolgálóból (AS) és egy jegykiadó kiszolgálóból (TGS). A Kerberos "jegyek" (úgynevezett Kerberos-jegyek) alapján működik, amelyek a felhasználók személyazonosságának igazolására szolgálnak.

Kerberos adatbázis: A kulcselosztó központ (KDC) a titkos kulcsok adatbázisát tartja fenn; a hálózaton minden egység - legyen az ügyfél vagy kiszolgáló - megosztja a titkos kulcsot, amelyet csak ő maga és a KDC ismer. E kulcs ismerete az egyes entitások személyazonosságának igazolására szolgál. Két entitás közötti kommunikációhoz a KDC egy munkamenetkulcsot generál, amelyet a felek kommunikációjuk biztonságossá tételére használhatnak.

A "Kerberos-kiszolgáló" kifejezés általában a KDC-re utal. A megbízhatóság érdekében lehetséges tartalék KDC-ket használni. Ezeket "Kerberos slave szervereknek" nevezik. Minden szolga szinkronizálja adatbázisát a Kerberos mester szerverről.

A "Kerberizált alkalmazáskiszolgáló" kifejezés általában olyan Kerberizált programokra utal, amelyekkel az ügyfelek Kerberos-jegyek segítségével kommunikálnak a hitelesítéshez. Például a Kerberos telnet-kiszolgáló egy példa a Kerberizált alkalmazáskiszolgálóra . Míg a "Kerberizált alkalmazások" kifejezés a Kerberizált alkalmazáskiszolgáló ügyféloldalára utal, például a Kerberos telnet kliens egy példa a Kerberizált alkalmazásokra.

A protokoll biztonsága nagymértékben függ:

1. A résztvevők lazán szinkronizált időt tartanak fenn.
2. Rövid életű hitelességi nyilatkozat: a Kerberos-jegyek.

A protokoll egyszerűsített leírása

A következő rövidítéseket használjuk:

·         AS = Hitelesítési kiszolgáló

·         TGS = Jegykiadó kiszolgáló

·         SS vagy Server = Service Server (kiszolgáló felhasználó, aki a szolgáltatását kéri, mint például egy nyomtatási kiszolgáló, egy fájlkiszolgáló, stb...).

·         TGT = Ticket Granting Ticket (Kerberos-jegy a TGS számára. A kapcsolódó rendszer készíti el, majd a TGS-szel való beszélgetéshez használják).

Röviden, az ügyfél egy hosszú távú megosztott titok segítségével hitelesíti magát a kapcsolódó rendszer felé, és a kapcsolódó rendszertől jegyet kap. Később az ügyfél ezt a jegyet felhasználhatja arra, hogy további jegyeket szerezzen az SS-hez ugyanannak a megosztott titoknak a felhasználásával. Ezek a jegyek felhasználhatók az SS felé történő hitelesítés bizonyítására.

A protokoll részletesebben

Felhasználói ügyfélalapú bejelentkezési lépések:

1. A felhasználó az ügyfélgépen megadja a felhasználónevet és a jelszót.
2. Az ügyfél egy egyirányú függvényt (többnyire Hash-függvényt) hajt végre a megadott jelszóval, és ez lesz az ügyfél/felhasználó titkos kulcsa.

Ügyfél-hitelesítési lépések:

1. Az ügyfél egyértelmű szövegű üzenetet küld a kapcsolódó rendszernek, amelyben a felhasználó nevében szolgáltatásokat kér.
   Üzenetminta: "XYZ felhasználó szeretne szolgáltatásokat kérni".
   Megjegyzés: Sem a titkos kulcs, sem a jelszó nem kerül elküldésre a kapcsolódó rendszerhez.
2. A kapcsolódó rendszer ellenőrzi, hogy az ügyfél szerepel-e az adatbázisában. Ha igen, a kapcsolódó rendszer a következő két üzenetet küldi vissza az ügyfélnek:
• A üzenet: Az ügyfél/TGS munkamenetkulcsa az ügyfél/felhasználó titkos kulcsával titkosítva.
• B üzenet: TGT (amely tartalmazza az ügyfél azonosítóját, az ügyfél hálózati címét, a jegy érvényességi idejét és az ügyfél/TGS munkamenetkulcsot), a TGS titkos kulcsával titkosítva.
3. Miután az ügyfél megkapta az A és B üzenetet, visszafejti az A üzenetet, hogy megkapja az ügyfél/TGS munkamenetkulcsot. Ezt a munkamenetkulcsot használja a TGS-szel való további kommunikációhoz. Ezen a ponton az ügyfél elegendő információval rendelkezik ahhoz, hogy hitelesítse magát a TGS felé.
   Megjegyzés: Az ügyfél nem tudja visszafejteni a B üzenetet, mivel az a TGS titkos kulcsával van titkosítva.

Ügyfélszolgálati engedélyezési lépések:

1. A szolgáltatások igénylésekor az ügyfél a következő két üzenetet küldi a TGS-nek:
• C üzenet: A B üzenet TGT-jéből és a kért szolgáltatás azonosítójából áll.
• Üzenet D: Hitelesítő (amely az ügyfél azonosítójából és az időbélyegzőből áll), az ügyfél/TGS munkamenetkulccsal titkosítva.
2. A C és D üzenet kézhezvételekor a TGS a C üzenetből kinyeri a B üzenetet, és a TGS titkos kulcsával visszafejti a B üzenetet. Így kapja meg az ügyfél/TGS munkamenetkulcsot. E kulcs segítségével a TGS visszafejti a D üzenetet (Authenticator), és a következő két üzenetet küldi az ügyfélnek:
• E üzenet: Ügyfél-kiszolgáló közötti jegy (amely tartalmazza az ügyfél azonosítóját, az ügyfél hálózati címét, az érvényességi időt és az ügyfél/kiszolgáló munkamenetkulcsot), az SS titkos kulcs segítségével titkosítva.
• F üzenet: Az ügyfél/kiszolgáló munkamenetkulcsa az ügyfél/TGS munkamenetkulccsal titkosítva.

Ügyfélszolgálati kérelem lépései:

1. Miután az ügyfél megkapta az E és F üzeneteket a TGS-től, elegendő információval rendelkezik ahhoz, hogy hitelesítse magát az SS felé. Az ügyfél csatlakozik az SS-hez, és elküldi a következő két üzenetet:
• E üzenet: az előző lépésből (az ügyfél-kiszolgáló közötti jegy, az SS titkos kulcsával titkosítva).
• G üzenet: egy új hitelesítő, amely tartalmazza az ügyfél azonosítóját, az időbélyeget, és az ügyfél/szerver munkamenetkulccsal van titkosítva.
2. Az SS a saját titkos kulcsa segítségével visszafejti a jegyet, hogy visszakapja az ügyfél/szerver munkamenetkulcsot. A munkamenetkulcsot használva az SS visszafejti a Hitelesítőt, és a következő üzenetet küldi az ügyfélnek, hogy megerősítse valódi személyazonosságát és az ügyfél kiszolgálására való hajlandóságát:
• H üzenet: az ügyfél hitelesítőjében található időbélyegző plusz 1, az ügyfél/szerver munkamenetkulccsal titkosítva.
3. Az ügyfél az ügyfél/kiszolgáló munkamenetkulcs segítségével visszafejti a megerősítést, és ellenőrzi, hogy az időbélyegző megfelelően frissült-e. Ha igen, akkor az ügyfél megbízhat a kiszolgálóban, és megkezdheti a kiszolgálóhoz intézett szolgáltatási kérések kibocsátását.
4. A kiszolgáló biztosítja a kért szolgáltatásokat az ügyfél számára.

Hátrányok

• Egyetlen hibapont: A központi szerver folyamatos rendelkezésre állását igényli. Ha a Kerberos-kiszolgáló nem működik, senki sem tud bejelentkezni. Ez több Kerberos-kiszolgáló és vészhelyzeti hitelesítési mechanizmusok használatával oldható meg.
• A Kerberos megköveteli, hogy az összes érintett állomás órája szinkronizálva legyen. A jegyeknek van egy időbeli rendelkezésre állási periódusa, és ha az állomás órája nincs szinkronizálva a Kerberos-kiszolgáló órájával, a hitelesítés sikertelen lesz. Az alapértelmezett konfiguráció megköveteli, hogy az óraidők legfeljebb 10 perc távolságra legyenek egymástól. A gyakorlatban általában a Network Time Protocol (NTP) protokollt használják az összes állomás szinkronizálására.
• Az adminisztrációs protokoll nem szabványosított, és a kiszolgáló implementációi között eltér. A jelszóváltoztatásokat az RFC 3244 írja le.
• Mivel az összes felhasználó titkos kulcsa a központi szerveren van tárolva, a szerver kompromittálása az összes felhasználó titkos kulcsát veszélyezteti.
• Egy kompromittált ügyfél kompromittálja a felhasználó jelszavát.

Kapcsolódó oldalak

• Személyazonosság-kezelés
• Biztonságos távoli jelszó protokoll (SRP)
• Általános biztonsági szolgáltatási alkalmazásprogram-interfész (GSS-API)