Kerberos (protokoll)

Ajalugu ja areng

MIT töötas välja Kerberose, et kaitsta projekti Athena pakutavaid võrguteenuseid. Protokoll sai nime Kreeka mütoloogilise tegelase Kerberose (või Kerberose) järgi, kes on Kreeka mütoloogias tuntud kui Hadesi kolmepealine koletislik valvekoer. Protokollist on olemas mitu versiooni; versioonid 1-3 on kasutusel ainult MIT-siseselt.

Steve Miller ja Clifford Neuman, kes olid Kerberose 4. versiooni (mis kasutas 56-bitise võtmega DES-krüpteerimisalgoritmi) peamised loojad, avaldasid selle versiooni 1989. aastal, kuigi nad olid selle peamiselt projekti Athena jaoks ette näinud.

Versioon 5, mille kavandasid John Kohl ja Clifford Neuman, ilmus 1993. aastal RFC 1510-na (mis muutus 2005. aastal vananenuks RFC 4120-ga), eesmärgiga ületada versiooni 4 piirangud ja turvaprobleemid. MIT teeb Kerberose 5. versiooni rakendamise vabalt kättesaadavaks BSD-litsentsile sarnase tarkvaralitsentsi alusel.

Mitmed ettevõtted kasutasid Kerberose 5. versiooni kaubanduslikus tarkvaras, sealhulgas:

·         Microsofti Windows 2000 ja hilisemad versioonid kasutavad vaikimisi autentimismeetodina Kerberost.
Mõned Microsofti täiendused Kerberose protokollide komplekti on dokumenteeritud dokumendis RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols".
RFC 4757 dokumenteerib Microsofti RC4 salakirja kasutamist.
Kuigi Microsoft kasutab Kerberose protokolli, ei kasuta ta MIT tarkvara[1].

·         Apple'i Mac OS X kasutab samuti Kerberost nii oma kliendi- kui ka serveriversioonis.

·         Red Hat Linuxi versioon 4 ja hilisemad versioonid kasutavad Kerberos't nii kliendi- kui ka serveriversioonis.

2005. aastal tutvustas IETF Kerberose töörühm Kerberose 5. versiooni [2] uusi ajakohastatud spetsifikatsioone:

·         "Krüpteerimise ja kontrollsumma spetsifikatsioonid" (RFC 3961),

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

·         Kerberose 5. versiooni spetsifikatsiooni "Kerberos Network Authentication Service (V5)" (RFC 4120) uus väljaanne. See versioon kaotab RFC 1510, täpsustab protokolli ja selle kasutusotstarbe aspekte üksikasjalikumalt ja selgemalt,

·         GSS-API spetsifikatsiooni uus väljaanne "Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Versioon 2." (RFC 4121).

2007. aastal moodustas MIT Kerberose konsortsiumi, et jätkata arendamist.

Protokoll

Kerberos kasutab alusena Needham-Schroederi protokolli. See kasutab usaldusväärset kolmanda osapoole autentimist, mida nimetatakse "võtmejaotuskeskuseks (KDC)", mis koosneb kahest loogiliselt eraldiseisvast osast: autentimisserver (AS) ja piletit väljastav server (TGS). Kerberos töötab "piletite" (mida nimetatakse Kerberose piletiteks) alusel, mille abil tõendatakse kasutajate identiteeti.

Kerberose andmebaas: Iga üksus võrgus - nii klient kui ka server - jagab salajase võtme, mida teab ainult tema ise ja KDC. Selle võtme teadmine on iga üksuse identiteedi tõendamiseks. Kahe üksuse vahelise suhtluse jaoks genereerib KDC seansivõtme, mida nad saavad kasutada oma suhtluse kaitsmiseks.

Mõiste "Kerberose server" viitab üldiselt KDC-le. Usaldusväärsuse tagamiseks on võimalik kasutada KDC-de varukoopiaid. Neid nimetatakse "Kerberos'e teenindavateks serveriteks". Kõik orjad sünkroonivad oma andmebaase Kerberose peaserverist.

Mõiste "Kerberiseeritud rakendusserver" viitab üldiselt Kerberiseeritud programmidele, millega kliendid suhtlevad, kasutades autentimiseks Kerberose pileteid. Näiteks Kerberos telnet server on näide Kerberiseeritud rakendusserverist . Kuigi terminit "Kerberiseeritud rakendused" kasutatakse Kerberiseeritud rakendusserveri kliendipoole viitamiseks , Näiteks Kerberos telnet-klient on Kerberiseeritud rakenduste näide.

Protokolli turvalisus sõltub suuresti:

1. Osalejad, kes hoiavad aega lõdvalt sünkroonis.
2. Lühiajaline autentsuse deklaratsioon: Kerberose piletid.

Protokolli lihtsustatud kirjeldus

Kasutatakse järgmisi lühendeid:

·         AS = autentimisserver

·         TGS = piletite väljastamise server

·         SS või Server = Service Server (serveri kasutaja, kes taotleb oma teenust, näiteks printimisserver, failiserver jne...).

·         TGT = Ticket Granting Ticket (Kerberose pilet TGSi jaoks. Koostab AS, seejärel kasutatakse TGSiga suhtlemiseks).

Lühidalt öeldes autentib klient end kõrvalsüsteemi ees pikaajalise jagatud saladuse abil ja saab kõrvalsüsteemilt pileti. Hiljem saab klient selle pileti abil saada täiendavaid pileteid SSi jaoks, kasutades sama jagatud saladust. Neid pileteid saab kasutada SS-i autentimise tõendamiseks.

Protokolli üksikasjalikumalt

Kasutaja kliendipõhised sisselogimise sammud:

1. Kasutaja sisestab kasutajanime ja salasõna kliendimasinas.
2. Klient täidab sisestatud parooliga ühesuunalise funktsiooni (enamasti Hash-funktsiooni) ja sellest saab kliendi/kasutaja salajane võti.

Kliendi autentimise sammud:

1. Klient saadab kõrvalsüsteemile selge tekstiga sõnumi, milles taotleb kasutaja nimel teenuseid.
   Näidisõnum: "Kasutaja XYZ soovib taotleda teenuseid".
   Märkus: kõrvalsüsteemile ei saadeta salajast võtit ega parooli.
2. Kõrvalsüsteem kontrollib, kas klient on tema andmebaasis. Kui ta on, saadab kõrvalsüsteem kliendile tagasi järgmised kaks teadet:
• Teade A: kliendi/TGSi seansivõti, mis on krüpteeritud kliendi/kasutaja salajase võtmega.
• Teade B: TGT (mis sisaldab kliendi ID-d, kliendi võrguaadressi, pileti kehtivusaega ja kliendi/TGSi seansivõtit), mis on krüpteeritud TGSi salajase võtme abil.
3. Kui klient on saanud sõnumid A ja B, dekrüpteerib ta sõnumi A, et saada kliendi/TGSi seansivõti. Seda seansivõtit kasutatakse edasiseks suhtlemiseks TGSiga. Sel hetkel on kliendil piisavalt teavet, et end TGSi ees autentida.
   Märkus: Klient ei saa sõnumit B dekrüpteerida, kuna see on krüpteeritud TGSi salajase võtmega.

Klienditeeninduse autoriseerimise sammud:

1. Teenuste taotlemisel saadab klient TGSile kaks järgmist sõnumit:
• Teade C: koosneb sõnumi B TGT-st ja taotletava teenuse ID-st.
• Sõnum D: Autentifikaator (mis koosneb kliendi ID-st ja ajatemplist), mis on krüpteeritud kliendi/TGSi seansivõti abil.
2. Sõnumite C ja D kättesaamisel otsib TGS sõnumi B sõnumist C. Ta dekrüpteerib sõnumi B TGSi salajase võtme abil. See annab talle kliendi/TGSi seansivõtme. Seda võtit kasutades dekrüpteerib TGS sõnumi D (autentifikaator) ja saadab kliendile järgmised kaks sõnumit:
• Teade E: Kliendilt serverile suunatud pilet (mis sisaldab kliendi ID-d, kliendi võrgu aadressi, kehtivusaega ja kliendi/serveri seansivõti), mis on krüpteeritud SS salajase võtmega.
• Teade F: kliendi/serveri seansivõti, mis on krüpteeritud kliendi/TGSi seansivõti.

Klienditeeninduse taotluse sammud:

1. Kui klient saab TGSilt sõnumid E ja F, on tal piisavalt teavet, et end SSi ees autentida. Klient võtab ühendust SS-iga ja saadab kaks järgmist sõnumit:
• Sõnum E: eelmisest sammust (kliendi ja serveri vaheline pilet, mis on krüpteeritud SS salajase võtmega).
• Sõnum G: uus autentimisvahend, mis sisaldab kliendi ID-d, ajatemplit ja on krüpteeritud kliendi/serveri seansivõtmega.
2. SS dekrüpteerib pileti oma salajase võtme abil, et saada välja kliendi/serveri seansivõti. Seansivõtit kasutades dekrüpteerib SS autentifikaatori ja saadab kliendile järgmise sõnumi, et kinnitada oma tegelikku identiteeti ja valmisolekut klienti teenindada:
• Sõnum H: kliendi autentimisseadmes leitud ajatempel pluss 1, mis on krüpteeritud kliendi/serveri seansivõtme abil.
3. Klient dekrüpteerib kinnituse, kasutades kliendi/serveri seansivõtit, ja kontrollib, kas ajatempel on õigesti ajakohastatud. Kui jah, siis saab klient usaldada serverit ja võib hakata serverile teenuspäringuid esitama.
4. Server pakub kliendile soovitud teenuseid.

Puudused

• Ühtne veapunkt: See nõuab keskserveri pidevat kättesaadavust. Kui Kerberose server ei tööta, ei saa keegi sisse logida. Selle probleemi saab lahendada mitme Kerberos-serveri ja hädaolukorra autentimismehhanismide kasutamisega.
• Kerberos nõuab, et kõigi kaasatud hostide kellad oleksid sünkroonitud. Piletitel on ajaline kättesaadavusperiood ja kui hostide kell ei ole sünkroniseeritud Kerberose serveri kellaga, siis autentimine ebaõnnestub. Vaikimisi konfiguratsioon nõuab, et kellaaegade vahe ei oleks suurem kui 10 minutit. Praktikas kasutatakse tavaliselt Network Time Protocol (NTP), et hoida kõik hostid sünkroonis.
• Haldusprotokoll ei ole standardiseeritud ja erineb serverite rakenduste vahel. Paroolide muutmist on kirjeldatud RFC 3244-s.
• Kuna kõikide kasutajate salajased võtmed on salvestatud keskserveris, siis ohustab selle serveri kahjustamine kõigi kasutajate salajasi võtmeid.
• Kompromiteeritud klient ohustab kasutaja salasõna.

Seotud leheküljed

• Identiteedi haldamine
• Turvaline kaugjuhtimise parooliprotokoll (SRP)
• Üldine turvateenuste rakendusprogrammi liides (GSS-API)