Kerberos (Protokoll)

Kerberos

Kerberos on arvuti võrgu autentimis protokoll, mis lubab sõlmedel info vahetust pidada üle mitte-turvaliste võrkude, et tõestada oma identiteeti üksteisele turvalisel viisil. Programmi loojad panid põhirõhu klient-serveri mudelile ja see tagab vastastikuse autentimise. Mõlemad, nii server kui ka kasutaja, kinnitavad üksteise identiteeti. Kerberose protokolli sõnumid on kaitstud igasugu pealtkuulamise ja taasesituse rünnakute vastu.

Kerberos on ehtitatud sümeetrilise võtme krüptograafial ja vajab usaldatud kolmandat osapoolt ning lisavalikuna võib kasutada avaliku võtme krüptograafiat kasutade asümeetrilise võtme krütpograafiat autentimise teatud faaside käigus.

Kerberosest on olemas ka tasuta tarkvara pakk, mida annab välja Massachusetts Tehnoloogia Instituut (MIT).

Ajalugu ja arendus

MIT arendas Kerberose et kaitsta Project Athena poolt pakutavaid võrguteenususeid. Protokoll sai enda nime Kreeka mütoloogiast pärit Kerberose nimelise tegelase järgi, kes mütoloogia järgi oli võigas kolmepealine Hadese valvekoer.

Protokollist esineb erinevaid versioone: versioonid 1-3 toimisid ainult MIT sisemiselt. Steve Miller ja Clifford Neuman (Kerberos versioon 4 peaarendajad) väljastasid Versioon 4 hilistes 80'dates, hoides endiselt pearõhku Project Athena'le.

Versioon 5 (arendajad John Kohl ja Clifford Neuman) ilmus RFC 1510 nime all aastal 1993(see vananes RFC 4120. aastal 2005) kavatsusega ületada eelmise versiooni limitatsioonid ja turva probleemid. MIT annab Kerberose rakendamise vabakasutusse BSD'le sarnastele koopiaõigustega. 2007 lõi MIT Kerberos Consortium'i, et soodustada arendamise jätku. Asutamise sponsorite hulka kuulusid näiteks: Sun Microsystems, Apple inc., Google, Microsoft ja Certify Corporation ning lisaks veel akadeemilised asutused nagu KTH - Kuninglik Tehnoloogia Instituut, Stanfordi ülikool ja MIT.

Ühendriikide ametivõimud klassifitseerisid Kerberose sõjamoonaks ja keelustasid selle ekspordi, kuna ta kasutas DES krüpteerimise algorütmi (56-biti võtmega). Ühendriikidest väljast tulnud Kerberos 4 rakendus KTH-KRB arendati Kuninglikus tehnoloogia instituudis Rootsis ning see anti ringlusesse väljaspool ühendriike enne kui ühendriigid suutsid oma krüptograafia ekspordi regulatsioone muuta ( kuskil aastas 2000). Rootslaste rakendus baseerus eBones'i nimelisel limiteeritud versioonil. eBones'i baseerus MIT'st eksporditud "luustiku" versioonil ( Krüpteeringu funktsioonid kui ka nende välja kutsumised olid eemaldatud) mis oli tehtud Kerberos versioon 4 patch-level 9'st.

Heimdal, Kerberos versioon 5 rakendus, avaldati põhimõteliselt sama inimeste grupi poolt, kes avaldasid KTH-KRB. Windows 2000 ja hilisemad, kasutavad Kerberost kui nende vaikimisi autentimise meetodit. Mõned Windowsi lisandid Kerberose protokolli komplektist on dokumenteeritud RFC 3344 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols". RFC 4757 dokumenteerib Microsofti RC4 siffri kasutust. Microsoft küll kasutab Kerberose protokolli, kuid ta ei kasuta MIT tarkvara.

Paljud UNIX ja UNIX'ilikud operatsiooni süsteemid (FreeBSD, Apple Mac OS X, Red Hat Enterprise Linux 4, Sun'i Solaris, IBM'i AIX, HP'e OpenVMS ja paljud muud) sisaldavad tarkvara Kerberose kasutaja või teenuse autentimiseks. Alates 2005 uuendab IETF Kerberose töö grupp spetsifikatsioone. Hiljutised uuendused sisaldavad:

• Encryption and Checksum Specifications" (RFC 3961).
• Advanced Encryption Standard (AES) Encryption for Kerberos 5 (RFC 3962).
• Kerberos V5 spetsifikatsiooni uus väljalase "The Kerberos Network Authentication Service (V5)" (RFC 4120). Selle versiooniga vananeb RFC 1510, lisaks selgitab prtokolli aspekte ja kavatsetud kasutust selgemas ja detailsemas selgituses.
• GSS-API spetsifikatsiooni uus väljalase "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2." (RFC 4121).

Protokoll

Teooria

Kerberos kasutab oma põhjaks Needham-Schroederi sümeetrilist protokolli. See kasutab usaldatud kolmandat osapoolt, võtme jagamis keskust (KCD), mis koosneb kahest loogiliselt jagatud osast: autentimise serverist(AS) ja võtmeid lubavast serverist (TGS). Kerberos töötab "Piletite" baasil, mis töötavad kasutaja identiteedi tõestamisel. KDC hooldab salajaste võtmete andmebaasi; iga võrgus olev entiteet (server või klient) jagab salajast võtit, mida vaid tema ja KDC teab. Selle võtme teadmine on entiteedi identiteedi tõestamise aluseks. Kahe entiteedi vahelise suhtluse jaoks loob KDC sessiooni võtme, mida nad saavad kasutada, et teha turvaliseks nende vastastikused toimetused. Protokolli turvalisus tugineb suuresti osalejate lõdvalt sünkroniseeritud aja säilitamisel ja lühiajalise väidetele autentsusele nimega "Kerberose piletid".

Kirjeldus

Klient autendib ennast autentimise serverile

ja saab vastu pileti (kõik piletid on ajatemplitega).

Järgmisena võtab klient ühendust piletit lubava serveriga (TGS) ja piletit kasutades demonstreerib ta oma identiteeti ning palub teenust.

Kui klient on teenuse saamiseks sobiv, saadab piletit lubav server järgmise pileti kliendile.

Järgmisena võtab klient ühendust Teenuse serveriga

ning pileti kasutusega tõestab ta, et talle on lubatud saada teenust

Faaside detailid on kirjeldatud järgnevalt.

Kasutaja Kliendi-baasil sisselogimine

1. Kasutaja sisestab oma kasutajanime ja parooli kliendiga masinasse.

2. Klient sooritab ühesuunalise funktsiooni (tavaliselt Hash) parooli sisestamisel ja see muutub kliendi/kasutaja salajaseks võtmeks.

Kliendi autentimine

1. Klient saadab puhastekst sõnumi kasutaja ID'ga autentimis serverile kliendi poolsete teenuste soovidega (tähelepanek: salajast võtit ega parooli ei saadeta autentimis serverile). Autentimis server genereerib salajase võtme kasutaja parooli, mida on võimalik leida andmebaasis (näiteks Windows Serveri Active Directory's), hashides.

2. Autentimis server kontrollib, kas klient on tema andmebaasis. Kui on, siis autentimis server saadab kliendile tagasi kaks järgmist sõnumit:

• Sõnum A: Client/TGS Session Key encrypted using the secret key of the client/user.
• Sõnum B: Ticket-to Get-Ticket (mis sisaldab kliendi ID'd, kliendi võrguaadressi, pileti kestvus perioodi ja kliendi/piletit-lubava serveri sessiooni võtit) encrypted using the secret key of the TGS.

3. Niipea kui klient saab sõnumi A ja B, püüab ta dekrüpteerida sõnumit A salajase võtmega, mis on loodud kasutaja poolt sisestatud parooliga. Kui kasutaja sisestas parooli, mis ei kattu autentimis serveri andmebaasis olevaga, on kliendi salajane võti erinev ning sõnumi A dekrüpteerimine ebaõnnestub. Õige parooli ja salajase võtmega klient dekrüpteerib sõnumi A ja omab Kliendi/Piletit-lubava serveri sessiooni võtme. Seda võtit kasutatakse piletit-lubava serveri suhtluses. (Tähelepanek: klient ei saa sõnumit B dekrüpteerida, kuna see on krüpteeritud piletit-lubava serveri salajase võtmega.) Esialgu on kliendil piisavalt informatsiooni, et alustada piletit-lubava serveriga autentimist.

Kliendi teenuse autorisatsioon

1. Teenuste küsimiseks saadab klient järgmised kaks sõnumit piletit-lubava serverisse:

• Sõnum C: koosneb pilet pileti saamise serverilt sõnumiga B ja soovitud teenuse ID'ga.
• Sõnum D: Kliendi/ piletit-lubava server sessiooni võtmest krüpteeritud autentija (koosneb kliendi ID'st ja ajatemplist)

2. Sõnumite C ja D saamisel, piletit-lubava server võtab sõnumi B välja sõnumist C. Dekrüpteerib sõnumi B kasutades piletit-lubava server salajast võtit. See annab "Kliendi/piletit-lubava serveri sessiooni võtme". Seda võtit kasutades dekrüpteerib piletit-lubav server sõnumi D (Autentija) ja saadab järgnevad kaks sõnumit kliendile:

• Sõnum E: Client-to-server ticket (sisaldab kliendi ID'd, kliendi võrguaadressi, kestvus perioodi ja Klient/server sessiooni võtit) encrypted using the service's secret key.
• Sõnum F: Client/server session key encrypted with the Client/TGS Session Key.

[edit]Client Service Request Upon receiving messages E and F from TGS, the client has enough information to

authenticate itself to the SS. The client connects to the SS and sends the following two

messages: Message E from the previous step (the client-to-server ticket, encrypted using service's

secret key). Message G: a new Authenticator, which includes the client ID, timestamp and is encrypted

using client/server session key. The SS decrypts the ticket using its own secret key to retrieve the Client/Server

Session Key. Using the sessions key, SS decrypts the Authenticator and sends the

following message to the client to confirm its true identity and willingness to serve

the client: Message H: the timestamp found in client's Authenticator plus 1, encrypted using the

Client/Server Session Key. The client decrypts the confirmation using the Client/Server Session Key and checks

whether the timestamp is correctly updated. If so, then the client can trust the server

and can start issuing service requests to the server. The server provides the requested services to the client. [edit]Drawbacks

Single point of failure: It requires continuous availability of a central server. When

the Kerberos server is down, no one can log in. This can be mitigated by using multiple

Kerberos servers and fallback authentication mechanisms. Kerberos has strict time requirements, which means the clocks of the involved hosts must

be synchronized within configured limits. The tickets have a time availability period

and if the host clock is not synchronized with the Kerberos server clock, the

authentication will fail. The default configuration per MIT requires that clock times

are no more than five minutes apart. In practice Network Time Protocol daemons are

usually used to keep the host clocks synchronized. The administration protocol is not standardized and differs between server

implementations. Password changes are described in RFC 3244. Since all authentication is controlled by a centralized KDC, compromise of this

authentication infrastructure will allow an attacker to impersonate any user.