Kerberos

Versiunea actuală a paginii nu a fost încă examinată de colaboratori experimentați și poate diferi semnificativ de versiunea revizuită pe 21 martie 2020; verificarea necesită 21 de modificări .

Kerberos /kɛərbərəs/ este un protocol de autentificare în rețea care oferă un mecanism de autentificare reciprocă a unui client și server înainte de a stabili o conexiune între ele. Kerberos efectuează autentificarea ca un serviciu de autentificare terță parte de încredere folosind un secret criptografic partajat, cu condiția ca pachetele care călătoresc printr-o rețea nesigură să poată fi interceptate, modificate și utilizate de către un atacator. Kerberos este construit pe criptografia cu chei simetrice și necesită un centru de distribuție a cheilor. Extensiile Kerberos pot oferi utilizarea criptografiei cu cheie publică în anumiți pași de autentificare.

Istoricul creației

Prima versiune a protocolului Kerberos a fost creată în 1983 la Massachusetts Institute of Technology (MIT) ca parte a proiectului Athena.. Scopul principal al proiectului a fost dezvoltarea unui plan de introducere a calculatoarelor în procesul educațional MIT și a software-ului aferent. Proiectul a fost educațional, dar rezultatul final a inclus mai multe produse software care sunt încă utilizate pe scară largă astăzi (cum ar fi X Window System ). Acest protocol a devenit disponibil public începând cu versiunea 4.

Concepte de bază

Să subliniem conceptul de bază al protocolului Kerberos. Să presupunem că există doi oameni care cunosc același secret, cunoscut doar de acești doi. Atunci oricare dintre ei poate fi ușor sigur că are de-a face cu partenerul său. Pentru a face acest lucru, trebuie doar să verifice dacă interlocutorul său cunoaște secretul împărtășit.

Exemplu.

Punctul 1. Acord privind parola. Lasă-l pe Alice să comunice cu Bob. În acest caz, Bob folosește informațiile numai atunci când este sigur că informațiile sunt primite de la Alice. Pentru a evita falsificarea, au convenit între ei asupra unei parole pe care doar ei doi o cunosc. Când primește un mesaj, Bob poate concluziona din scrisoare dacă interlocutorul său cunoaște parola. Dacă interlocutorul lui Bob știe parola, atunci se poate argumenta că interlocutorul lui este Alice.

Punctul 2. Apariția unei probleme de transmitere a parolei. Acum haideți să stabilim cum să le arătăm lui Alice și lui Bob cunoașterea parolei. Desigur, puteți include pur și simplu parola în corpul e-mailului. De exemplu: „Bună Bob. Parola noastră. Dacă Bob și Alice ar fi siguri că nimeni nu le citește scrisorile, atunci această metodă ar putea fi folosită. Dar, din păcate, mailul este transmis printr-o rețea în care lucrează alți utilizatori, printre care se numără și o Eve curioasă. Eve și-a pus sarcina de a afla parola, cunoscută doar de Bob și Alice, cu care fac schimb de mesaje între ei. Acum este destul de clar că nu puteți specifica parola pur și simplu în corpul scrisorii. Aceasta înseamnă că nu poți vorbi deschis despre parolă, dar, în același timp, trebuie să anunți interlocutorul că știi parola.

Punctul 3. Rezolvarea problemei transmiterii parolei. Protocolul Kerberos rezolvă problema transmiterii parolei folosind criptografia cu chei secrete. În loc să-și spună reciproc o parolă, participanții la o sesiune de comunicare schimbă o cheie criptografică, a cărei cunoaștere confirmă identitatea interlocutorului. Dar pentru ca o astfel de tehnologie să fie posibilă, este necesar ca cheia partajată să fie simetrică , adică cheia trebuie să asigure atât criptarea, cât și decriptarea mesajului.

Punctul 4. Problema schimbului de parole. Există o problemă importantă atunci când utilizați protocoale simple precum cel descris mai sus. În cazul lui Bob și Alice, trebuie să înțelegeți cum sunt de acord asupra unei chei secrete care să corespundă între ei. Desigur, oamenii se pot întâlni și sunt de acord, dar mașinile participă și la negocierile de rețea. Dacă Alice este înțeleasă ca un program client, iar Bob este un serviciu pe un server de rețea, atunci nu se pot întâlni în niciun fel. Problema este că atunci când un client trebuie să trimită un mesaj către mai multe servere, în acest caz va trebui să achiziționeze o cheie separată pentru fiecare server. Și atunci serverul va avea nevoie de atâtea chei secrete câte clienți are. Necesitatea de a stoca atât de multe chei pe fiecare computer reprezintă un risc pentru întregul sistem de securitate.

Punctul 5. Rezolvarea problemei schimbului de parole. Pentru a rezolva aceste probleme, proiectul Athena a dezvoltat un protocol special - Kerberos. Prin analogie cu mitologia greacă antică, acest protocol a fost numit după câinele cu trei capete care a protejat ieșirea din regatul lui Hades - Cerberus , sau mai precis - Cerberus. Cei trei șefi ai Cerberus din protocol corespund celor trei participanți la comunicarea securizată: un client, un server și un intermediar de încredere între ei. Rolul intermediarului aici este jucat de Centrul de distribuție a cheilor, KDC.

Centrul de distribuție a cheilor KDC (sau TGS - server de bilete sau de permisiuni)

Un centru de distribuție a cheilor (KDC) este un serviciu care rulează pe un server securizat din punct de vedere fizic. Centrul păstrează o bază de date cu informații despre conturile tuturor clienților din rețea. Împreună cu informații despre fiecare abonat, baza de date a centrului de distribuție a cheilor stochează o cheie criptografică cunoscută doar de acest abonat și de serviciul centrului. Această cheie este folosită pentru a conecta clientul cu centrul.

Client la server prin KDC

Dacă clientul dorește să contacteze serverul, el trimite un mesaj centrului de distribuție a cheilor. Centrul trimite fiecărui participant la sesiune copii ale cheii de sesiune valabile pentru o perioadă scurtă de timp. Scopul acestor chei este de a autentifica clientul și serverul. O copie a cheii de sesiune trimisă la server este criptată folosind cheia pe termen lung a serverului și trimisă clientului este criptată cu cheia pe termen lung a clientului. Teoretic, pentru a îndeplini funcțiile unui intermediar de încredere, este suficient ca un centru de distribuție a cheilor să trimită cheile de sesiune direct abonaților de securitate. Cu toate acestea, este extrem de dificil să implementezi o astfel de schemă în practică. Prin urmare, în practică, se utilizează o schemă diferită de gestionare a parolelor, ceea ce face ca protocolul Kerberos să fie mult mai eficient.

Bilete de sesiune

Ca răspuns la o solicitare din partea unui client care intenționează să se conecteze la server, serviciul KDC trimite ambele copii ale cheii de sesiune către client. Mesajul destinat clientului este criptat cu o cheie pe termen lung partajată între client și KDC, iar cheia de sesiune pentru server, împreună cu informații despre client, este încorporată într-un bloc de date numit bilet de sesiune. Întregul bilet de sesiune este apoi criptat cu o cheie pe termen lung pe care numai serviciul KDC și acest server o cunosc. După aceea, toată responsabilitatea procesării biletului, care poartă cheia de sesiune criptată, revine clientului, care trebuie să-l livreze serverului. La primirea răspunsului KDC, clientul extrage biletul și copia sa a cheii de sesiune din acesta, pe care le plasează în stocare securizată (nu se află pe disc, ci în RAM ). Când trebuie să contacteze un server, clientul îi trimite un mesaj constând dintr-un bilet, încă criptat folosind cheia pe termen lung a serverului și propriul său autentificator, criptat cu cheia de sesiune. Această autentificare, combinată cu autentificatorul, constituie acreditările prin care serverul determină „identitatea” clientului. Serverul, după ce a primit „cartea de identitate” a clientului, în primul rând, folosind cheia sa secretă, decriptează biletul de sesiune și extrage cheia de sesiune din acesta, pe care apoi o folosește pentru a decripta autentificatorul clientului. Dacă totul merge bine, se ajunge la concluzia că identitatea clientului a fost emisă de un intermediar de încredere, adică de către serviciul KDC. Clientul poate solicita serverului să efectueze autentificarea reciprocă. În acest caz, serverul, folosind copia sa a cheii de sesiune, criptează marcajul de timp de la autentificatorul clientului și îl trimite clientului ca propriul său autentificator. Un avantaj al utilizării acreditărilor de sesiune este că serverul nu trebuie să stocheze cheile de sesiune pentru a comunica cu clienții. Acestea sunt stocate în „cache-ul de acreditări” al clientului, care trimite biletul către server de fiecare dată când dorește să-l contacteze. Serverul, la rândul său, după ce a primit biletul de la client, îl decriptează și extrage cheia de sesiune. Când cheia nu mai este necesară, serverul o poate șterge pur și simplu din memorie. Această metodă are un alt avantaj: clientul nu trebuie să contacteze KDC înainte de fiecare sesiune cu un anumit server. Acreditările de sesiune pot fi reutilizate. În cazul furtului acestora, se stabilește data de expirare a biletului, pe care KDC o indică în structura de date propriu-zisă. Acest timp este determinat de politica Kerberos specifică domeniului. De obicei, perioada de valabilitate a biletelor nu depășește opt ore, adică durata standard a unei sesiuni în rețea. Când un utilizator se deconectează, memoria cache a acreditărilor este resetată și toate acreditările de sesiune, împreună cu cheile de sesiune, sunt distruse.

Evoluția protocolului

Versiunile timpurii

MIT a dezvoltat Kerberos pentru a securiza serviciile de rețea furnizate de proiectul Athena. Protocolul a fost numit după personajul mitologic grec Kerberos (sau Cerberus ), cunoscut în mitologia greacă ca monstruosul câine de pază cu trei capete Hades. Există mai multe versiuni ale protocolului. Versiunile timpurii ale Kerberos (de la 1 la 3) au fost create intern de MIT și utilizate în scopuri de testare. Aceste implementări au conținut limitări semnificative și au fost utile doar pentru explorarea de noi idei și identificarea problemelor care ar putea apărea în timpul dezvoltării.

Steve Miller și Clifford Neuman , principalii designeri ai Kerberos versiunea 4 (care folosea algoritmul de criptare DES cu chei de 56 de biți), au publicat această versiune în 1989, deși încă o planificau în primul rând la acea vreme în proiectul Athena.

Kerberos 4

Kerberos 4 a fost publicat pentru prima dată pe 24 ianuarie 1989 . A fost prima versiune distribuită în afara MIT, pregătită pentru ca mai mulți furnizori să o includă în sistemele lor de operare. În plus, alte proiecte mari de sisteme distribuite (de exemplu, Andrew File System ) au folosit ideile Kerberos 4 pentru sistemele lor de autentificare.

Bazele a ceea ce urma să devină Kerberos 4 au fost descrise în cartea albă Athena [1] , iar versiunea finală a fost solidificată în codul sursă al implementării de referință publicată de MIT.

Cu toate acestea, din cauza restricțiilor guvernului SUA privind exportul de software criptat, Kerberos 4 nu a putut fi distribuit în afara Statelor Unite. Deoarece Kerberos 4 a folosit algoritmul DES pentru criptare , organizațiile din afara Statelor Unite nu au putut folosi software-ul în mod legal. Ca răspuns, echipa de dezvoltare a MIT a creat o versiune specială a Kerberos 4, excluzând tot codul legat de criptare din acesta. Aceste măsuri au permis eludarea restricției la export.

Mai târziu, Errol Young de la Universitatea Bond din Australia a adăugat propria sa implementare a DES la această versiune. Se numea „E-Bones” (prescurtare de la „oase criptate” [2] ) și era liber să fie distribuit în afara Statelor Unite.

În 2006, a fost anunțat suportul pentru Kerberos 4 [3] .

Kerberos 5

Pentru a depăși problemele de securitate ale versiunii anterioare, John Kohl și Clifford Neuman au dezvoltat versiunea 5 a protocolului, care a fost publicată în 1993 în RFC 1510 . De-a lungul timpului, în 2005, grupul de lucru IETF Kerberos a început să se ocupe de specificație. Documentele pe care le-au publicat includ:

caracteristici de criptare și sumă de control ( RFC 3961 );
standardul avansat de criptare (AES) ( RFC 3962 );
Kerberos 5 „The Kerberos Network Authentication Service (V5)” ( RFC 4120 ), clarifică unele aspecte ale RFC 1510 și intenționează să fie utilizat pentru o descriere mai detaliată și mai clară;
noua ediție a specificației GSS-API „Mecanismul Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mecanism: Version 2.” ( RFC 4121 ).

În iunie 2006, a fost introdus RFC 4556 care descrie o extensie pentru versiunea 5 numită PKINIT (criptografia cu chei publice pentru autentificarea inițială în Kerberos ) . Acest RFC a descris cum se utilizează criptarea asimetrică în timpul fazei de autentificare a clientului .

În anul următor (2007), MIT a format Consorțiul Kerberos pentru a promova dezvoltarea ulterioară.

Utilizare și distribuire

Distribuția implementării Kerberos are loc sub drepturi de autor, similar drepturilor BSD.

În prezent, multe sisteme de operare acceptă acest protocol, inclusiv:

Windows 2000 și versiuni ulterioare, care utilizează Kerberos ca metodă de autentificare la un domeniu între membri. Unele completări la acest protocol sunt reflectate în RFC 3244 „Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols”. RFC 4757 descrie utilizarea RC4 Kerberos pe Windows;
diverse sisteme de operare UNIX și UNIX (Apple Mac OS X , Red Hat Enterprise Linux 4, FreeBSD , Solaris , AIX , OpenVMS ). Cu toate acestea, există două implementări open source cele mai utilizate - MIT Kerberos și Heimdal, cel din urmă fiind creat inițial în Suedia din cauza restricțiilor privind exportul de software criptografic din Statele Unite .

Cum funcționează

Kerberos 4

Kerberos 4 se bazează în mare parte pe protocolul Needham-Schroeder , dar cu două modificări semnificative.

Prima modificare a protocolului a redus numărul de mesaje trimise între client și serverul de autentificare.
A doua modificare, mai semnificativă, a protocolului de bază este introducerea conceptului TGT ( ticket granting ticket ) , care permite utilizatorilor să se autentifice împotriva mai multor servicii folosind datele lor de încredere o singură dată.

Ca rezultat, protocolul Kerberos 4 conține două componente logice:

Server de autentificare (abbr. CA, ing. Authentication Server, prescurtare AS )

Server pentru emiterea de bilete sau permisiuni (ing. Ticket Granting Server, abr. TGS ).

De obicei, aceste componente sunt livrate ca un singur program care rulează pe un centru de distribuție cheie (KDC - conține o bază de date de autentificare/parole pentru utilizatori și servicii care utilizează Kerberos).

Serverul de autentificare îndeplinește o singură funcție: primește o solicitare care conține numele clientului care solicită autentificare și îi returnează un bilet criptat pentru a obține un bilet (TGT). Utilizatorul poate folosi acest bilet pentru a solicita bilete ulterioare pentru alte servicii. În majoritatea implementărilor Kerberos, durata de viață a TGT este de 8-10 ore. După aceea, clientul trebuie să o solicite din nou de la serverul de autentificare.

Primul mesaj trimis centrului de distribuție a cheilor este o solicitare către serverul de autentificare, cunoscută și sub numele de AS_REQ. Acest mesaj este trimis în text clar și conține identitatea clientului, marca temporală a clientului și identificatorul serverului de acordare a biletelor (TGS).

Atunci când centrul de distribuție a cheilor primește un mesaj AS_REQ, verifică dacă clientul de la care a venit cererea există și marca temporală a acestuia este aproape de ora locală a centrului (de obicei ± 5 minute). Această verificare nu este făcută pentru a proteja împotriva reluărilor (mesajul este trimis în text clar), ci pentru a verifica sincronizarea. Dacă cel puțin una dintre verificări eșuează, un mesaj de eroare este trimis clientului și acesta nu este autentificat.

Dacă are succes, serverul de autentificare generează o cheie aleatorie de sesiune care va fi partajată între client și serverul de bilete sau de acordare (această cheie protejează cererile viitoare de bilete pentru alte servicii). Centrul de distribuție a cheilor creează 2 copii ale cheii de sesiune: una pentru client și una pentru serverul de acordare a biletelor.

Centrul de distribuție a cheilor răspunde apoi clientului cu un mesaj de server de autentificare (AS_REP) criptat cu cheia pe termen lung a clientului. Acest mesaj include TGT criptat cu cheia TGS, o copie a cheii de sesiune pentru client, durata de viață a biletului și ID-ul TGS (TGT conține: o copie a cheii de sesiune pentru TGS, ID-ul clientului, durata de viață a biletului, Marca temporală a Centrului de distribuție a cheilor (KDC), client adresa IP).

Când utilizatorul dorește să acceseze serviciul, el va pregăti un mesaj pentru TGS_REQ care conține 3 părți: identificatorul serviciului, copia TGT primită anterior și autentificatorul (autentificatorul constă dintr-un marcaj de timp criptat cu cheia de sesiune primită de la server de autentificare și servește la protejarea împotriva repetărilor).

La primirea unei cereri de bilet de la un client, KDC generează o nouă cheie de sesiune pentru interacțiunea client/serviciu. Apoi trimite un mesaj de răspuns (TGS_REP) criptat cu cheia de sesiune primită de la serverul de autentificare. Acest mesaj conține noua cheie de sesiune, bilet de serviciu criptat cu cheia de serviciu pe termen lung, ID de serviciu și durata de viață a biletului (conține o copie a noii chei de sesiune, ID-ul clientului, durata de viață a biletului, ora locală a centrului de distribuție a cheilor, adresa IP a clientului ).

Detaliile ultimului pas, trimiterea biletului de serviciu către serverul de aplicații, nu sunt standardizate de Kerberos 4, deci implementarea acestuia este complet dependentă de aplicație.

Kerberos 5

Kerberos 5 este o dezvoltare a celei de-a patra versiuni, include toate funcționalitățile anterioare și conține multe extensii. Cu toate acestea, din punct de vedere al implementării, Kerberos 5 este un protocol complet nou.

Principalul motiv pentru apariția celei de-a cincea versiuni a fost imposibilitatea extinderii. De-a lungul timpului, un atac cu forță brută asupra DES utilizat în Kerberos 4 a devenit relevant, dar câmpurile folosite în mesaje aveau o dimensiune fixă și nu a fost posibil să se utilizeze un algoritm de criptare mai puternic.

Pentru a rezolva această problemă, s-a decis crearea unui protocol extensibil care să poată fi utilizat pe diverse platforme bazate pe tehnologia ASN.1. Acest lucru a permis utilizarea diferitelor tipuri de criptare în tranzacții. Datorită acestui fapt, a fost implementată compatibilitatea cu versiunea anterioară. În plus, KDC are capacitatea de a alege cel mai sigur protocol de criptare acceptat de părțile participante.

În plus, protocolul original Kerberos 4 este supus enumerarii dicționarului. Această vulnerabilitate este legată de faptul că KDC emite un TGT criptat la cerere oricărui client. Importanța acestei probleme este subliniată și de faptul că utilizatorii aleg de obicei parole simple.

Pentru a face acest atac mai dificil, Kerberos 5 a introdus pre-autentificarea. În această etapă, KDC solicită utilizatorului să-și verifice identitatea înainte de a putea primi un bilet.

Politica KDC este responsabilă pentru pre-autentificare, dacă este necesară, atunci utilizatorul va primi un mesaj KRB_ERROR la prima solicitare către serverul de autentificare. Acest mesaj va spune clientului să trimită o solicitare AS_REQ cu acreditările sale pentru a se autentifica. Dacă KDC nu le recunoaște, atunci utilizatorul va primi un alt mesaj KRB_ERROR care indică o eroare și nu va fi emis niciun TGT.

Descriere formală Notații criptografice utilizate în protocoalele de autentificare și schimb de chei

$A$	Identificatorii lui Alice ( Alice ), inițiatorul sesiunii
$B$	Identificatorul lui Bob ( Bob ), partea din care se stabilește sesiunea
$T$	Identificatorul Trent ( Trent ), o parte intermediară de încredere
$K_{A},K_{B},K_{T}$	Cheile publice ale lui Alice, Bob și Trent
$K_{A}^{-1},K_{B}^{-1},K_{T}^{-1}$	Cheile secrete ale lui Alice, Bob și Trent
$E_{A},\stanga\{...\dreapta\}_{K_{A}}$	Criptarea datelor cu cheia lui Alice sau cheia comună a lui Alice și Trent
$E_{B},\stanga\{...\dreapta\}_{K_{B}}$	Criptarea datelor cu cheia lui Bob sau cheia comună a lui Bob și Trent
$\left\{...\right\}_{K_{B}^{-1}},\left\{...\right\}_{K_{A}^{-1}}$	Criptarea datelor cu cheile secrete ale lui Alice, Bob (semnătură digitală)
$eu$	Numărul secvenței sesiunii (pentru a preveni atacurile de reluare)
$K$	Cheie aleatorie de sesiune care trebuie utilizată pentru criptarea simetrică a datelor
$E_{K},\stânga\{...\dreapta\}_{K}$	Criptarea datelor cu o cheie de sesiune temporară
$T_{A},T_{B}$	Marcaje temporale adăugate mesajelor de către Alice și, respectiv, Bob
$R_{A},R_{B}$	Numere aleatoare ( nonce ) care au fost alese de Alice și, respectiv, de Bob

Protocolul folosește doar criptarea simetrică și presupune că fiecare corespondent (Alice și Bob) partajează o cheie secretă cu o terță parte de încredere (Trent).

Alice își trimite actul și Bob persoanei de încredere (Trent):

Alice\la \stanga\{A,B\dreapta\}\la Trent

Trent generează două mesaje. Primul include marcajul de timp , durata de viață a cheii , noua cheie de sesiune pentru Alice și Bob și ID-ul lui Bob . Acest mesaj este criptat cu cheia partajată a lui Alice și Trent. Al doilea mesaj conține același, cu excepția identificatorului - a fost înlocuit cu identificatorul lui Alice . Mesajul în sine este criptat cu cheia partajată a lui Trent și Bob: $T_{T}$ $L$ $K$ $B$ $A$

Trent\la \stanga\{E_{A}\left(T_{T},L,K,B\dreapta), E_{B}\stanga(T_{T},L,K,A\dreapta)\dreapta \}\la Alice

Alice generează un mesaj din propriul ID și un marcaj de timp , apoi criptează mesajul cu cheia de sesiune și îl trimite lui Bob împreună cu al doilea mesaj de la Trent: $A$ $T_{T}$ $K$

Alice\la \stanga\{E_{K}\left(A,T_{T}\dreapta),E_{B}\left(T_{T},L,K,A\dreapta)\dreapta\}\la Bob

Pentru propria sa autentificare, Bob criptează marcajul de timp modificat cu o cheie de sesiune partajată și o trimite lui Alice: $T_{T}+1$ $K$

Bob\la \left\{E_{K}\left(T_{T}+1\dreapta)\dreapta\}\la Alice

O presupunere importantă este că ceasurile tuturor participanților la protocol sunt sincronizate. Cu toate acestea, în practică, sincronizarea este utilizată cu o precizie de câteva minute, cu istoricul transmisiei stocat (pentru a detecta repetarea) pentru o perioadă de timp.

Descriere detaliată

Modul în care funcționează Kerberos 5 în prezent este următorul:

Logare utilizator:

Utilizatorul introduce un nume de utilizator și o parolă pe computerul client.
Mașina client îndeplinește o funcție unidirecțională (de obicei un hash) asupra parolei, iar rezultatul devine cheia secretă a clientului/utilizatorului.

Autentificare client:

Clientul trimite o cerere (AS_REQ) către CA pentru a obține acreditările de autentificare și apoi le furnizează serverului TGS (mai târziu le va folosi pentru a obține acreditări fără solicitări suplimentare de utilizare a cheii secrete a utilizatorului.) Această solicitare conține:
- ID-ul clientului, marca temporală a acestuia și ID-ul serverului.
Dacă politica KDC necesită pre-autentificare, atunci utilizatorul primește un mesaj KRB_ERROR, ca răspuns la care trimite o a doua cerere, dar cu date de autentificare.
CA verifică dacă există un astfel de client în baza de date. Dacă da, CA trimite înapoi un mesaj (AS_REP) care include:
- Cheia de sesiune a clientului sau TGS, identificatorul TGS și durata de viață a biletului , criptate cu cheia privată a clientului .
- TGT (care include ID-ul clientului și adresa de rețea, marcajul de timp KDC, perioada de valabilitate a biletului și cheia de sesiune client sau TGS) criptate cu cheia secretă TGS.

Dacă nu, atunci clientul primește un nou mesaj care indică faptul că a apărut o eroare.

La primirea mesajului, clientul își decriptează partea pentru a obține Cheia de sesiune a clientului, sau TGS. Această cheie de sesiune este utilizată pentru schimburi ulterioare cu serverul TGS. (Important: clientul nu poate decripta TGT deoarece este criptat cu cheia secretă TGS) În acest moment, utilizatorul are suficiente acreditări pentru a se conecta la TGS.

Autorizarea clientului pe TGS:

Pentru a solicita un serviciu, clientul generează o cerere pentru TGS (TGS_REQ) care conține următoarele date:
- TGT a primit mai devreme și ID de serviciu.
- Un autentificator (compus dintr-un ID de client și un marcaj de timp) criptat pe cheia de sesiune Client/TGS.
La primirea TGS_REQ, TGS extrage TGT-ul din acesta și îl decriptează folosind cheia secretă TGS. Aceasta îi oferă cheia de sesiune a clientului, sau TGS. Cu el, el decriptează autentificatorul. Apoi generează o cheie de sesiune client/serviciu și trimite un răspuns (TGS_REP) care include:
- Tichetul de serviciu (care conține ID-ul clientului, adresa rețelei clientului, marcajul de timp KDC, timpul de expirare a biletului și Cheia de sesiune client/serviciu) criptat cu cheia secretă a serviciului.
- Cheia de sesiune client/serviciu, identificatorul de serviciu și durata de viață a biletului criptate pe cheia de sesiune Client/TGS.

Solicitarea serviciului de către client:

După primirea TGS_REP, clientul are suficiente informații pentru a autoriza serviciul. Clientul se conectează la acesta și trimite un mesaj care conține:
- Biletul de serviciu criptat primit mai devreme.
- Un nou autentificator criptat cu cheia de sesiune client/serviciu și care include ID-ul clientului și marcajul de timp.
Serviciul decriptează biletul folosind cheia sa privată și obține cheia de sesiune client/serviciu. Folosind noua cheie, decriptează autentificatorul și trimite următorul mesaj clientului pentru a confirma că este gata să servească clientul și că serverul este cu adevărat cine pretinde a fi:
- Marca temporală specificată de client + 1 , criptată cu cheia de sesiune client/serviciu.
Clientul decriptează confirmarea utilizând cheia de sesiune client/serviciu și verifică dacă marca temporală a fost într-adevăr actualizată corect. Dacă da, atunci clientul poate avea încredere în server și poate începe să trimită cereri către server.
Serverul oferă clientului serviciul necesar.

PKINIT

Extensia PKINIT a afectat etapa de pre-autentificare a clientului, după care a început să apară după cum urmează:

Utilizatorul este identificat în sistem și își prezintă cheia privată.
Mașina client emite o cerere către CA (AS_REQ) indicând că va fi utilizată criptarea asimetrică. Diferența acestei cereri este că este semnată (folosind cheia privată a clientului) și, pe lângă informațiile standard, conține certificatul cheii publice ale utilizatorului.
La primirea cererii, KDC verifică mai întâi valabilitatea certificatului utilizatorului și apoi semnătura digitală (folosind cheia publică a utilizatorului primită) . După aceea, KDC verifică ora locală trimisă în cerere (pentru a se proteja împotriva reluărilor) .
După ce a verificat autenticitatea clientului, KDC generează un răspuns (AS_REP), în care, spre deosebire de versiunea standard, cheia de sesiune este criptată cu cheia publică a utilizatorului. În plus, răspunsul conține certificatul KDC și este semnat cu cheia sa privată (similar cu cererea clientului) .
La primirea răspunsului, utilizatorul verifică semnătura KDC și își decriptează cheia de sesiune (folosind propria lor privată) .

Alți pași au loc conform descrierii standard a Kerberos V5.

Dezavantaje și limitări

Punct unic de eșec: necesită un server central în orice moment. Când serverul Kerberos se defectează, utilizatorii noi nu se pot conecta. Acest lucru poate fi rezolvat cu mai multe servere Kerberos și mecanisme de autentificare alternativă.
Kerberos are cerințe stricte de timp, ceea ce înseamnă că ceasurile participanților trebuie să fie menținute sincronizate în limitele specificate. Acreditările au o durată de viață și dacă ceasul clientului nu este sincronizat cu ceasul serverului Kerberos, autentificarea va eșua. Configurația implicită necesită ca ceasurile să fie distanță de cel mult cinci minute. În practică, demonii Network Time Protocol sunt de obicei utilizați pentru a sincroniza ceasurile clienților.
Protocolul de administrare nu este standardizat și depinde de implementarea specifică a serverului. Modificarea parolei este descrisă în RFC 3244.
În cazul criptografiei simetrice (Kerberos poate funcționa atât folosind criptografia simetrică, cât și asimetrică (cheie publică), deoarece toate metodele de autentificare sunt gestionate central de centrul de distribuție a cheilor (KDC), această caracteristică a infrastructurii de autentificare va permite unui atacator să se usureze identității. un utilizator.
Fiecare serviciu de rețea care necesită o schimbare a numelui de gazdă va trebui să-și actualizeze propriul set de chei Kerberos. Acest lucru complică utilizarea găzduirii partajate și a clusterelor.
Kerberos necesită ca conturile de utilizator, clienții și utilizatorii de servicii de pe server să aibă încredere în serverul Kerberos (toți trebuie să fie în același domeniu cu Kerberos sau în domenii care au o relație de încredere între ele). Kerberos nu poate fi utilizat în cazurile în care utilizatorii doresc să se conecteze la servicii de la clienți necunoscuți/neîncrezători, cum ar fi pe internetul obișnuit.

Vulnerabilități

Cifrul DES poate fi folosit cu Kerberos, dar nu mai este un standard de internet deoarece este vulnerabil. Cu toate acestea, există vulnerabilități în multe produse care utilizează Kerberos care nu au fost actualizate pentru a înlocui DES cu cifruri mai noi, cum ar fi AES, de exemplu.

În noiembrie 2014, Microsoft a lansat un patch (MS14-068) pentru a remedia o vulnerabilitate în implementarea Windows a serverului KDC. Vulnerabilitatea, conform declarației, a permis utilizatorilor să-și „riște” privilegiile la nivel de domeniu.

Vezi și

Tehnologie de conectare unică
managementul identităţii
SPNEGO
S/Cheie
SRP (Secure Remote Password Protocol)
GSS-API (Generic Security Services Application Program Interface)
Protocolul de identitate a gazdei (HIP)

Note

↑ Plan tehnic Arhivat 1 ianuarie 2016 la Athena Project Wayback Machine .
↑ Istoricul numelui E-Bones (link inaccesibil)
↑ Anunțul de sfârșit de viață Kerberos Versiunea 4 . Consultat la 11 noiembrie 2011. Arhivat din original pe 3 noiembrie 2011. (nedefinit)

Literatură

Schneier B. Capitolul 3. Protocoale de bază. Protocolul Kerberos // Criptografie aplicată. Protocoale, algoritmi, cod sursă în limbaj C = Criptografie aplicată. Protocoale, algoritmi și cod sursă în C. - M. : Triumf, 2002. - P. 81. - 816 p. - 3000 de exemplare. - ISBN 5-89392-055-4 .
Schneier B. Capitolul 24. Exemple de implementări practice. Protocolul KERBEROS // Criptografie aplicată. Protocoale, algoritmi, cod sursă în limbaj C = Criptografie aplicată. Protocoale, algoritmi și cod sursă în C. - M. : Triumf, 2002. - S. 627-633. — 816 p. - 3000 de exemplare. - ISBN 5-89392-055-4 .
Jason Garman . 1-3 // Kerberos: Ghidul definitiv (neopr.) . - 2003. - ISBN 0-596-00403-6 .
Schneier B. Capitolul 24.5 Kerberos Bruce Schneier // Criptografie aplicată. Protocoale, algoritmi, cod sursă în limbaj C = Criptografie aplicată. Protocoale, algoritmi și cod sursă în C. - M. : Triumph, 2002. - 816 p. - 3000 de exemplare. - ISBN 5-89392-055-4 .

Link -uri

Protocoale de autentificare și schimb de chei
Cu algoritmi simetrici	Broasca cu gura lata Yahalom Protocolul Needham-Schroeder Protocolul Otway-Risa Kerberos Protocolul Newman-Stubblebine
Cu algoritmi simetrici si asimetrici	DASS Protocolul Denning-Sacco Protocolul Wu Lam SPKM
Protocoale și servicii utilizate pe Internet	OAuth Deschideți ID Windows Live ID