Kerberos (Protokoll): Difference between revisions

From ICO wiki
Jump to navigationJump to search
← Older edit
Rkorgmaa (talk | contribs)
91 edits
No edit summary
Rkorgmaa (talk | contribs)
91 edits
 
(13 intermediate revisions by the same user not shown)
Line 31: Line 31:
== Protokoll ==
== Protokoll ==


'''Teooria'''
=== 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.
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".
 
[edit]Description
The following is an intuitive description. The client authenticates itself to the
 
Authentication Server and receives a ticket. (All tickets are time-stamped.) 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:
=== Kirjeldus ===
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
Klient autendib ennast autentimise serverile
[[File:kerberos-client-server.jpg]]


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
ja saab vastu pileti (kõik piletid on ajatemplitega).


does not match the password in the AS database, the client's secret key will be
[[File:ticket-granting-ticket.jpg]]


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
Järgmisena võtab klient ühendust piletit lubava serveriga (TGS) ja piletit kasutades demonstreerib ta oma identiteeti ning palub teenust.  


used for further communications with the TGS. (Note: The client cannot decrypt Message
[[File:ticket-granting-server.jpg]]


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


information to authenticate itself to the TGS.
Kui klient on teenuse saamiseks sobiv, saadab piletit lubav server järgmise pileti kliendile.
[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.
[[File:encrypted-key.jpg]]
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
Järgmisena võtab klient ühendust Teenuse serveriga


messages to the client:
[[File:service-server.jpg]]
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.
ning pileti kasutusega tõestab ta, et talle on lubatud saada teenust
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
[[File:client-server-success.jpg]]


messages:
Faaside detailid on kirjeldatud järgnevalt.
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.
'''Kasutaja Kliendi-baasil sisselogimine'''
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
1. Kasutaja sisestab oma kasutajanime ja parooli kliendiga masinasse.


following message to the client to confirm its true identity and willingness to serve
2. Klient sooritab ühesuunalise funktsiooni (tavaliselt Hash) parooli sisestamisel ja see muutub kliendi/kasutaja salajaseks võtmeks.


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


Client/Server Session Key.
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.  
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  
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: Klient/piletit-lubava serveri sessiooni võti krüpteeriti kliendi/kasutaja poolse salajase võtmega.
* Sõnum B: Pilet Pileti saamiseks (mis sisaldab kliendi ID'd, kliendi võrguaadressi, pileti kestvus perioodi ja kliendi/piletit-lubava serveri sessiooni võtit) krüpteeriti kasutades piletit-lubava serveri salajast võtit.


and can start issuing service requests to the server.
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.  
The server provides the requested services to the client.
[edit]Drawbacks


Single point of failure: It requires continuous availability of a central server. When
'''Kliendi teenuse autorisatsioon'''


the Kerberos server is down, no one can log in. This can be mitigated by using multiple
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.  


Kerberos servers and fallback authentication mechanisms.
'''Kliendi teenuse päring'''
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
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.


and if the host clock is not synchronized with the Kerberos server clock, the
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.


authentication will fail. The default configuration per MIT requires that clock times
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.


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


usually used to keep the host clocks synchronized.
* 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.  
The administration protocol is not standardized and differs between server
* 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. MIT poolt seatud vaikiv säte 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.


implementations. Password changes are described in RFC 3244.
== Kasutatud materjaal ==
Since all authentication is controlled by a centralized KDC, compromise of this
* http://en.wikipedia.org/wiki/Kerberos_(protocol)
* http://learn-networking.com/network-security/how-kerberos-authentication-works


authentication infrastructure will allow an attacker to impersonate any user.
== Autor ==
Rain Kõrgmaa A22

Latest revision as of 22:04, 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: Klient/piletit-lubava serveri sessiooni võti krüpteeriti kliendi/kasutaja poolse salajase võtmega.
  • Sõnum B: Pilet Pileti saamiseks (mis sisaldab kliendi ID'd, kliendi võrguaadressi, pileti kestvus perioodi ja kliendi/piletit-lubava serveri sessiooni võtit) krüpteeriti kasutades piletit-lubava serveri salajast võtit.

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. MIT poolt seatud vaikiv säte 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

Autor

Rain Kõrgmaa A22

Retrieved from "https://wiki.itcollege.ee/index.php?title=Kerberos_(Protokoll)&oldid=21245"