Kerberos (Protokoll): Difference between revisions

From ICO wiki
Jump to navigationJump to search
Rkorgmaa (talk | contribs)
No edit summary
Rkorgmaa (talk | contribs)
Line 113: Line 113:
== Puudused ==
== Puudused ==


* Läbikukkumise ainuke punkt: Ta vajab pidevalt keskserveri olemasolu. Kui Kerberose server on maas, siis keegi ei saa sisse logida. Seda saab leevendada kasutades mitut Kerberose serverit ja äralangemise autentimise mehanisme.
* Kerberosel on ranged aja nõuded, mis tähendab tegutsevate hostide kellad peavad olema sünkroniseeritud teatud sättete limiiti. Piletitel on kättesaadavuse aja periood ja kui hosti kell ei ole sünkroniseeritud Kerberose serveri kellaga, kukub autentimine läbi. Vaikiv sätted MIT kohta nõuab et kella ajad ei oleks erinevad rohkem kui viis minutit. Praktikas reeglina kasutatakse Network Time Protocol daemone, et kellad oleks sünkroonis.
* Administratsiooni protokoll ei ole standardiseeritud ja erineb serverite teostamisel. Parooli muutused on kirjas RFC 3244.
* Kuna kõik autentimised on kontrollitud kesk KDC poolt, siis selle autentimis infrastruktuuri ohustamise korral on ründajal võimalik kehastada suvalist kasutajat.


Single point of failure: It requires continuous availability of a central server. When
== Kasutatud materjaal ==
[http://en.wikipedia.org/wiki/Kerberos_(protocol)]
[http://learn-networking.com/network-security/how-kerberos-authentication-works]


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


Kerberos servers and fallback authentication mechanisms.
== Autor ==
Kerberos has strict time requirements, which means the clocks of the involved hosts must
Rain Kõrgmaa A22
 
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.

Revision as of 21:27, 19 December 2010

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: Teenuse salajast võtit kasutades krüpteeriti Kliendi-serveri pilet (sisaldab kliendi ID'd, kliendi võrguaadressi, kestvus perioodi ja Klient/server sessiooni võtit).
  • Sõnum F: Kliendi/serveri sessiooni võti krüpteeriti Kliendi/piletit-lubav serveri sessiooni võtmega.

Kliendi teenuse päring

1. Sõnumite E ja F saamisega piletit-lubavalt serverilt, on kliendil piisavalt informatsiooni enese autentimiseks teenuse serveriga. Klient ühendab end teenuse serverisse ja saadab järgnevad kaks sõnumit:

  • Sõnum E eelnevast sammust (teenuse salajase võtmega krüpteeritud kliendi-serveri pilet)
  • Sõnum G: uus autentija, mis sisaldab kliendi ID'd, ajatemplit ja on krüpteeritud klient/serveri sessiooni võtmega.

2. Teenuse server dekrüpteerib pileti kasutades oma salajast võtit, et omandada klienti/serveri sessiooni võti. Võtme kasutamisega dekrüpteerib teenuse server autentija ja saadab järgneva sõnumi kliendile oma tõelise identiteedi ja teenimise valmisoleku:

  • Sõnum H: kliendi Autentijast leitud ajatempel plus 1, krüpteeritud kasutades klient/server sessiooni võtit.

3. Klient dekrüpteerib kinnituse kasutades klient/serveri sessiooni võtit ja kontrollib, kas ajatemplit on korrektselt uuendatud. Tegevuse õnnestumisel usaldab klient serverit ja saab alustada teenuste päringute saatmist serverile. Server varustab klienti soovitud teenustega.


Puudused

  • Läbikukkumise ainuke punkt: Ta vajab pidevalt keskserveri olemasolu. Kui Kerberose server on maas, siis keegi ei saa sisse logida. Seda saab leevendada kasutades mitut Kerberose serverit ja äralangemise autentimise mehanisme.
  • Kerberosel on ranged aja nõuded, mis tähendab tegutsevate hostide kellad peavad olema sünkroniseeritud teatud sättete limiiti. Piletitel on kättesaadavuse aja periood ja kui hosti kell ei ole sünkroniseeritud Kerberose serveri kellaga, kukub autentimine läbi. Vaikiv sätted MIT kohta nõuab et kella ajad ei oleks erinevad rohkem kui viis minutit. Praktikas reeglina kasutatakse Network Time Protocol daemone, et kellad oleks sünkroonis.
  • Administratsiooni protokoll ei ole standardiseeritud ja erineb serverite teostamisel. Parooli muutused on kirjas RFC 3244.
  • Kuna kõik autentimised on kontrollitud kesk KDC poolt, siis selle autentimis infrastruktuuri ohustamise korral on ründajal võimalik kehastada suvalist kasutajat.

Kasutatud materjaal

[1] [2]


Autor

Rain Kõrgmaa A22