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

Järgnev on intuitiivne kirjeldus. Klient autendib ennast autentimise serverile (AS)

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.

It then 

contacts the Ticket Granting Server, and using the ticket it demonstrates its identity

and asks for a service. If the client is eligible for the service, then the Ticket

Granting Server sends another ticket to the client. The client then contacts the Service

Server, and using this ticket it proves that it has been approved to receive the

service. A simplified and more detailed description of the protocol follows. The following

abbreviations are used: AS = Authentication Server SS = Service Server TGS = Ticket-Granting Server TGT = Ticket-to Get-Ticket The client authenticates to the AS once using a long-term shared secret (e.g. a

password) and receives a TGT from the AS. Later, when the client wants to contact some

SS, it can (re)use this ticket to get additional tickets from TGS, for SS, without

resorting to using the shared secret. These tickets can be used to prove authentication

to SS. The phases are detailed below. [edit]User Client-based Logon A user enters a username and password on the client machine. The client performs a one-way function (hash usually) on the entered password, and this

becomes the secret key of the client/user. [edit]Client Authentication The client sends a cleartext message of the user ID to the AS requesting services on

behalf of the user. (Note: Neither the secret key nor the password is sent to the AS.)

The AS generates the secret key by hashing the password of the user found at the

database (e.g. Active Directory in Windows Server). The AS checks to see if the client is in its database. If it is, the AS sends back the

following two messages to the client: Message A: Client/TGS Session Key encrypted using the secret key of the client/user. Message B: Ticket-to Get-Ticket (which includes the client ID, client network address,

ticket validity period, and the client/TGS session key) encrypted using the secret key

of the TGS. Once the client receives messages A and B, it attempts to decrypt message A with the

secret key generated from the password entered by the user. If the user entered password

does not match the password in the AS database, the client's secret key will be

different and thus unable to decrypt message A. With a valid password and secret key the

client decrypts message A to obtain the .Client/TGS Session Key. This session key is

used for further communications with the TGS. (Note: The client cannot decrypt Message

B, as it is encrypted using TGS's secret key.) At this point, the client has enough

information to authenticate itself to the TGS. [edit]Client Service Authorization When requesting services, the client sends the following two messages to the TGS: Message C: Composed of the TGT from message B and the ID of the requested service. Message D: Authenticator (which is composed of the client ID and the timestamp),

encrypted using the Client/TGS Session Key. Upon receiving messages C and D, the TGS retrieves message B out of message C. It

decrypts message B using the TGS secret key. This gives it the "client/TGS session key".

Using this key, the TGS decrypts message D (Authenticator) and sends the following two

messages to the client: Message E: Client-to-server ticket (which includes the client ID, client network

address, validity period and Client/Server Session Key) encrypted using the service's

secret key. Message 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.