Kerberos (protokols)

Vēsture un attīstība

MIT izstrādāja Kerberos, lai aizsargātu projekta Athena tīkla pakalpojumus. Protokols tika nosaukts grieķu mitoloģiskā tēla Kerbera (jeb Cerbera) vārdā, kas grieķu mitoloģijā bija pazīstams kā briesmīgs trīsgalvains Hades sargsunis. Pastāv vairākas protokola versijas; 1.-3. versiju izmanto tikai MIT iekšienē.

Stīvs Millers un Klifords Neimans, Kerberos 4. versijas (kurā tika izmantots DES šifrēšanas algoritms ar 56 bitu atslēgām) galvenie izstrādātāji, publicēja šo versiju 1989. gadā, lai gan viņi to bija izstrādājuši galvenokārt projektam Athena.

Džona Kola (John Kohl) un Kliforda Neimana (Clifford Neuman) izstrādātā 5. versija tika publicēta 1993. gadā kā RFC 1510 (2005. gadā to padarīja novecojušu ar RFC 4120), lai pārvarētu 4. versijas ierobežojumus un drošības problēmas. MIT nodrošina, ka Kerberos 5. versijas implementācija ir brīvi pieejama ar programmatūras licenci, kas ir līdzīga BSD licencei.

Vairāki uzņēmumi izmantoja Kerberos 5. versiju komerciālajā programmatūrā, tostarp:

·         Microsoft Windows 2000 un jaunākajās versijās kā noklusējuma autentifikācijas metode tiek izmantota Kerberos.
Daži Microsoft papildinājumi Kerberos protokolu komplektam ir dokumentēti dokumentā RFC 3244 "Microsoft Windows 2000 Kerberos paroles maiņas un paroles iestatīšanas protokoli".
RFC 4757 dokumentē, kā Microsoft izmanto RC4 šifru.
Lai gan Microsoft izmanto Kerberos protokolu, tas neizmanto MIT programmatūru[1].

·         Arī Apple Mac OS X izmanto Kerberos gan klienta, gan servera versijā.

·         Red Hat Linux 4. un jaunākā versija izmanto Kerberos gan klienta, gan servera versijā.

2005. gadā IETF Kerberos darba grupa ieviesa jaunu, atjauninātu Kerberos 5. versijas specifikāciju [2]:

·         "Šifrēšanas un kontrolsummu specifikācijas" (RFC 3961),

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

·         Kerberos 5. versijas specifikācijas "The Kerberos Network Authentication Service (V5)" (RFC 4120) jauns izdevums. Šajā versijā ir anulēts RFC 1510, precizēti protokola aspekti un paredzētais lietojums, sniedzot detalizētāku skaidru skaidrojumu,

·         GSS-API specifikācijas jaunais izdevums "Kerberos 5. versijas vispārējo drošības pakalpojumu lietojumprogrammu saskarnes (GSS-API) mehānisms: Versija 2." (RFC 4121).

2007. gadā MIT izveidoja Kerberos konsorciju, lai turpinātu izstrādi.

Protokols

Kerberos pamatā ir Needhama un Schrēdera protokols. Tas izmanto uzticamas trešās puses autentifikāciju, kas pazīstama kā "atslēgu sadales centrs (KDC)", kas sastāv no divām loģiski atsevišķām daļām: autentifikācijas servera (AS) un biļešu piešķiršanas servera (TGS). Kerberos darbojas, pamatojoties uz "biļetēm" (ko sauc par Kerberos biļetēm), kas kalpo lietotāju identitātes pierādīšanai.

Kerberos datubāze: Katra vienība tīklā - klients vai serveris - dalās ar slepeno atslēgu, kas zināma tikai tai un KDC. Zinot šo atslēgu, tiek pierādīta katras vienības identitāte. Saziņai starp divām vienībām KDC ģenerē sesijas atslēgu, ko tās var izmantot saziņas drošībai.

Termins "Kerberos serveris" parasti attiecas uz KDC. Uzticamības nolūkos ir iespējams izveidot KDC dublējumu. Tos dēvē par "Kerberos pakārtotajiem serveriem". Visi pakārtotie serveri sinhronizē savas datubāzes no galvenā Kerberos servera.

Termins "Kerberizēts lietojumprogrammu serveris" parasti attiecas uz Kerberizētām programmām, ar kurām klienti sazinās, autentifikācijai izmantojot Kerberos biļetes. Piemēram, Kerberos telnet serveris ir Kerberizēta lietojumprogrammu servera piemērs. Savukārt termins "Kerberizētās lietojumprogrammas" tiek lietots, lai apzīmētu Kerberizēto lietojumprogrammu servera klienta pusi , piemēram, Kerberos telnet klients ir Kerberizēto lietojumprogrammu piemērs.

Protokola drošība lielā mērā ir atkarīga no:

1. Dalībnieki, kas uztur brīvi sinhronizētu laiku.
2. Īstermiņa autentiskuma deklarācija: Kerberos biļetes.

Vienkāršots protokola apraksts

Tiks lietoti šādi saīsinājumi:

·         AS = autentifikācijas serveris

·         TGS = biļešu piešķiršanas serveris

·         SS vai Serveris = Pakalpojumu serveris (servera lietotājs, kas pieprasa tā pakalpojumu, piemēram, drukas serveri, failu serveri utt...).

·         TGT = biļetes piešķiršanas biļete (Kerberos biļete TGS. Sagatavo papildsistēma, pēc tam to izmanto sarunai ar TGS).

Īsumā klients autentificējas AS, izmantojot ilgtermiņa koplietošanas noslēpumu, un no AS saņem biļeti. Vēlāk klients var izmantot šo biļeti, lai saņemtu papildu biļetes SS, izmantojot to pašu koplietošanas noslēpumu. Šīs biļetes var izmantot, lai apliecinātu autentifikāciju SS.

Sīkāka informācija par protokolu

Lietotāja uz klientu balstīti pieteikšanās soļi:

1. Lietotājs klienta datorā ievada lietotājvārdu un paroli.
2. Klients veic vienvirziena funkciju (galvenokārt Hash funkciju) ievadītajai parolei, un tā kļūst par klienta/lietotāja slepeno atslēgu.

Klienta autentifikācijas soļi:

1. Klients nosūta atklātā teksta ziņojumu papildsistēmai, pieprasot pakalpojumus lietotāja vārdā.
   Ziņojuma paraugs: "Lietotājs XYZ vēlas pieprasīt pakalpojumus".
   Piezīme: ne slepenā atslēga, ne parole netiek nosūtīta papildsistēmai.
2. Papildsistēma pārbauda, vai klients ir tās datubāzē. Ja tas ir, papildsistēma klientam nosūta divus šādus ziņojumus:
• A ziņojums: klienta/TGS sesijas atslēga, kas šifrēta, izmantojot klienta/lietotāja slepeno atslēgu.
• B ziņojums: TGT (kas ietver klienta ID, klienta tīkla adresi, biļetes derīguma termiņu un klienta/TGS sesijas atslēgu), kas šifrēts, izmantojot TGS slepeno atslēgu.
3. Kad klients saņem ziņojumus A un B, tas atšifrē ziņojumu A, lai iegūtu klienta/TGS sesijas atslēgu. Šo sesijas atslēgu izmanto turpmākai saziņai ar TGS. Šajā brīdī klientam ir pietiekami daudz informācijas, lai autentificētu sevi TGS.
   Piezīme: Klients nevar atšifrēt ziņojumu B, jo tas ir šifrēts, izmantojot TGS slepeno atslēgu.

Klientu apkalpošanas autorizācijas soļi:

1. Pieprasot pakalpojumus, klients TGS nosūta šādus divus ziņojumus:
• C ziņojums: sastāv no B ziņojuma TGT un pieprasītā pakalpojuma ID.
• D ziņojums: Autentifikators (ko veido klienta ID un laika zīmogs), šifrēts, izmantojot klienta/TGS sesijas atslēgu.
2. Saņemot ziņojumus C un D, TGS no ziņojuma C iegūst ziņojumu B. Tā atšifrē ziņojumu B, izmantojot TGS slepeno atslēgu. Tādējādi tiek iegūta klienta/TGS sesijas atslēga. Izmantojot šo atslēgu, TGS atšifrē ziņojumu D (Autentifikators) un nosūta klientam šādus divus ziņojumus:
• E ziņojums: klienta-servera biļete (kas ietver klienta ID, klienta tīkla adresi, derīguma termiņu un klienta/servera sesijas atslēgu), kas šifrēta, izmantojot SS slepeno atslēgu.
• F ziņojums: klienta/servera sesijas atslēga, kas šifrēta ar klienta/TGS sesijas atslēgu.

Klientu apkalpošanas pieprasījuma soļi:

1. Saņemot ziņojumus E un F no TGS, klientam ir pietiekami daudz informācijas, lai autentificētos SS. Klients izveido savienojumu ar SS un nosūta šādus divus ziņojumus:
• Ziņojums E: no iepriekšējā soļa (klienta-servera biļete, kas šifrēta, izmantojot SS slepeno atslēgu).
• Ziņojums G: jauns autentifikators, kas ietver klienta ID, laika zīmogu un ir šifrēts, izmantojot klienta/servera sesijas atslēgu.
2. SS atšifrē biļeti, izmantojot savu slepeno atslēgu, lai iegūtu klienta/servera sesijas atslēgu. Izmantojot sesijas atslēgu, SS atšifrē autentifikatoru un nosūta klientam šādu ziņojumu, lai apstiprinātu savu patieso identitāti un gatavību apkalpot klientu:
• Ziņojums H: klienta autentifikatorā atrodamais laika zīmogs plus 1, šifrēts, izmantojot klienta/servera sesijas atslēgu.
3. Klients atšifrē apstiprinājumu, izmantojot klienta/servera sesijas atslēgu, un pārbauda, vai laika zīmogs ir pareizi atjaunināts. Ja tā, tad klients var uzticēties serverim un var sākt izdot serverim pakalpojumu pieprasījumus.
4. Serveris klientam nodrošina pieprasītos pakalpojumus.

Trūkumi

• Vienots kļūmes punkts: Tas prasa nepārtrauktu centrālā servera pieejamību. Ja Kerberos serveris nedarbojas, neviens nevar pieteikties. Šo problēmu var atrisināt, izmantojot vairākus Kerberos serverus un ārkārtas autentifikācijas mehānismus.
• Kerberos sistēmai ir jāsinhronizē visu iesaistīto mitekļu pulksteņi. Biļetēm ir noteikts laika pieejamības periods, un, ja saimnieka pulkstenis nav sinhronizēts ar Kerberos servera pulksteni, autentifikācija neizdosies. Noklusējuma konfigurācijā ir noteikts, ka pulksteņa laiki nedrīkst atšķirties vairāk par 10 minūtēm. Praksē parasti izmanto tīkla laika protokolu (NTP), lai sinhronizētu visus hostus.
• Administrēšanas protokols nav standartizēts, un serveru implementācijas atšķiras. Paroļu izmaiņas ir aprakstītas RFC 3244.
• Tā kā visu lietotāju slepenās atslēgas tiek glabātas centrālajā serverī, šā servera kompromitēšana apdraud visu lietotāju slepenās atslēgas.
• Kompromitēts klients apdraud lietotāja paroli.

Saistītās lapas

• Identitātes pārvaldība
• Drošs attālās paroles protokols (SRP)
• Vispārīgo drošības pakalpojumu lietojumprogrammu saskarne (GSS-API)