Kerberos (protocol)

Istoric și dezvoltare

MIT a dezvoltat Kerberos pentru a proteja serviciile de rețea furnizate de Proiectul Athena. Protocolul a fost numit după personajul mitologic grecesc Kerberos (sau Cerberus), cunoscut în mitologia greacă ca fiind monstruosul câine de pază cu trei capete al lui Hades. Există mai multe versiuni ale protocolului; versiunile 1-3 sunt utilizate doar la nivel intern la MIT.

Steve Miller și Clifford Neuman, principalii proiectanți ai versiunii 4 a Kerberos (care folosea algoritmul de criptare DES cu chei de 56 de biți), au publicat această versiune în 1989, cu toate că au destinat-o în primul rând Proiectului Athena.

Versiunea 5, concepută de John Kohl și Clifford Neuman, a apărut ca RFC 1510 în 1993 (devenită caducă prin RFC 4120 în 2005), cu intenția de a depăși limitările și problemele de securitate ale versiunii 4. MIT pune la dispoziție gratuit o implementare a Kerberos versiunea 5, sub o licență software similară celei utilizate de licența BSD.

Mai multe companii au folosit Kerberos versiunea 5 în software comercial, printre care:

·         Microsoft Windows 2000 și versiunile ulterioare folosesc Kerberos ca metodă de autentificare implicită.
Unele adăugiri Microsoft la suita de protocoale Kerberos sunt documentate în RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols".
RFC 4757 documentează utilizarea de către Microsoft a cifrului RC4.
Deși Microsoft utilizează protocolul Kerberos, nu folosește software-ul MIT[1].

·         Mac OS X de la Apple utilizează, de asemenea, Kerberos atât în versiunea client, cât și în cea server.

·         Red Hat Linux versiunea 4 și versiunile ulterioare utilizează Kerberos atât în versiunea client, cât și în cea server.

În 2005, grupul de lucru IETF Kerberos a introdus o nouă specificație actualizată pentru Kerberos versiunea 5 [2]:

·         "Encryption and Checksum Specifications" (RFC 3961),

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

·         O nouă ediție a specificației Kerberos versiunea 5 "The Kerberos Network Authentication Service (V5)" (RFC 4120). Această versiune elimină RFC 1510, clarifică aspecte ale protocolului și ale utilizării preconizate într-o explicație clară și mai detaliată,

·         O nouă ediție a specificației GSS-API "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Versiunea 2." (RFC 4121).

În 2007, MIT a format Kerberos Consortium pentru continuarea dezvoltării.

Protocol

Kerberos folosește ca bază protocolul Needham-Schroeder. Acesta utilizează un terț de încredere pentru autentificare, cunoscut sub numele de "centru de distribuție a cheilor (KDC)", care este format din două părți separate din punct de vedere logic: un server de autentificare (AS) și un server de acordare a biletelor (TGS). Kerberos funcționează pe baza unor "bilete" (denumite bilete Kerberos) care servesc la dovedirea identității utilizatorilor.

Baza de date Kerberos: Centrul de distribuire a cheilor (KDC) menține o bază de date cu chei secrete; fiecare entitate din rețea - client sau server - împarte o cheie secretă cunoscută doar de ea însăși și de KDC. Cunoașterea acestei chei servește la dovedirea identității fiecărei entități. Pentru comunicarea dintre două entități, KDC generează o cheie de sesiune pe care acestea o pot utiliza pentru a-și securiza comunicațiile.

Termenul "server Kerberos" se referă în general la KDC. Din motive de fiabilitate, este posibil să existe KDC-uri de rezervă. Acestea sunt denumite "servere Kerberos slave". Toți sclavii își sincronizează bazele de date de la serverul Kerberos principal.

Termenul "server de aplicații Kerberized" se referă, în general, la programele Kerberized cu care clienții comunică folosind bilete Kerberos pentru autentificare. De exemplu, serverul Kerberos telnet este un exemplu de server de aplicații Kerberizat . În timp ce termenul "aplicații Kerberizate" este utilizat pentru a se referi la partea client a serverului de aplicații Kerberizate , De exemplu, clientul Kerberos telnet este un exemplu de aplicații Kerberizate

Securitatea protocolului depinde în mare măsură de:

1. Participanții menținând o sincronizare slabă a timpului.
2. O declarație de autenticitate de scurtă durată: biletele Kerberos.

Descriere simplificată a protocolului

Se vor utiliza următoarele abrevieri:

·         AS = Server de autentificare

·         TGS = Ticket Granting Server

·         SS sau Server = Service Server (Utilizator al serverului care solicită serviciul său, cum ar fi un server de imprimare, un server de fișiere etc...)

·         TGT = Ticket Granting Ticket (bilet Kerberos pentru TGS. Pregătit de AS, apoi utilizat pentru a vorbi cu TGS).

Pe scurt, clientul se autentifică la AS folosind un secret partajat pe termen lung și primește un bilet de la AS. Ulterior, clientul poate utiliza acest tichet pentru a obține tichete suplimentare pentru SS utilizând același secret partajat. Aceste bilete pot fi folosite pentru a dovedi autentificarea la SS.

Protocolul în detaliu

Etape de conectare a utilizatorului bazate pe client:

1. Un utilizator introduce un nume de utilizator și o parolă pe calculatorul client.
2. Clientul execută o funcție unidirecțională (în general o funcție Hash) asupra parolei introduse, iar aceasta devine cheia secretă a clientului/utilizatorului.

Etapele de autentificare a clientului:

1. Clientul trimite un mesaj în clar către AS prin care solicită servicii în numele utilizatorului.
   Exemplu de mesaj: "Utilizatorul XYZ dorește să solicite servicii".
   Notă: Nici cheia secretă, nici parola nu sunt trimise către AS.
2. AS verifică dacă clientul se află în baza sa de date. În caz afirmativ, AS trimite înapoi clientului următoarele două mesaje:
• Mesajul A: Cheia de sesiune client/TGS criptată cu ajutorul cheii secrete a clientului/utilizatorului.
• Mesajul B: TGT (care include ID-ul clientului, adresa de rețea a clientului, perioada de valabilitate a biletului și cheia de sesiune client/TGS) criptată cu ajutorul cheii secrete a TGS.
3. Odată ce clientul primește mesajele A și B, acesta decriptează mesajul A pentru a obține cheia de sesiune client/TGS. Această cheie de sesiune este utilizată pentru comunicările ulterioare cu TGS. În acest moment, clientul are suficiente informații pentru a se autentifica în fața TGS.
   Notă: Clientul nu poate decripta mesajul B, deoarece acesta este criptat cu ajutorul cheii secrete a TGS.

Etapele de autorizare a serviciului pentru clienți:

1. Atunci când solicită servicii, clientul trimite următoarele două mesaje către TGS:
• Mesajul C: compus din TGT din mesajul B și din ID-ul serviciului solicitat.
• Mesajul D: Autentificatorul (care este compus din ID-ul clientului și marca temporală), criptat cu ajutorul cheii de sesiune Client/TGS.
2. La primirea mesajelor C și D, TGS extrage mesajul B din mesajul C. Acesta decriptează mesajul B folosind cheia secretă TGS. În acest fel se obține cheia de sesiune Client/TGS. Folosind această cheie, TGS decriptează mesajul D (Authenticator) și trimite următoarele două mesaje clientului:
• Mesajul E: bilet client-server (care include ID-ul clientului, adresa de rețea a clientului, perioada de valabilitate și cheia de sesiune client/server) criptat cu ajutorul cheii secrete SS.
• Mesajul F: cheia de sesiune client/server criptată cu cheia de sesiune client/TGS.

Pași de solicitare a serviciilor pentru clienți:

1. La primirea mesajelor E și F de la TGS, clientul dispune de suficiente informații pentru a se autentifica la SS. Clientul se conectează la SS și trimite următoarele două mesaje:
• Mesajul E: de la etapa anterioară (biletul Client-to-Server, criptat cu ajutorul cheii secrete SS).
• Mesajul G: un nou autentificator, care include ID-ul clientului, data și ora și este criptat cu ajutorul cheii de sesiune client/server.
2. SS decriptează biletul folosind propria cheie secretă pentru a obține cheia de sesiune client/server. Utilizând cheia de sesiune, SS decriptează autentificatorul și trimite următorul mesaj clientului pentru a confirma adevărata sa identitate și dorința de a servi clientul:
• Mesaj H: marca temporală găsită în autentificatorul clientului plus 1, criptată cu ajutorul cheii de sesiune client/server.
3. Clientul decriptează confirmarea utilizând cheia de sesiune client/server și verifică dacă marca temporală este actualizată corect. În caz afirmativ, clientul poate avea încredere în server și poate începe să emită cereri de servicii către server.
4. Serverul furnizează clientului serviciile solicitate.

Dezavantaje

• Punct unic de eșec: Necesită disponibilitatea continuă a unui server central. Când serverul Kerberos nu funcționează, nimeni nu se poate conecta. Acest lucru poate fi rezolvat prin utilizarea mai multor servere Kerberos și a unor mecanisme de autentificare de urgență.
• Kerberos necesită ca ceasurile tuturor gazdelor implicate să fie sincronizate. Tichetele au o perioadă de disponibilitate în timp, iar dacă ceasul gazdei nu este sincronizat cu ceasul serverului Kerberos, autentificarea va eșua. Configurația implicită impune ca orele ceasurilor să nu fie la o diferență mai mare de 10 minute. În practică, Network Time Protocol (NTP) este utilizat de obicei pentru a menține sincronizarea tuturor gazdelor.
• Protocolul de administrare nu este standardizat și diferă de la o implementare la alta a serverului. Modificările de parole sunt descrise în RFC 3244.
• Deoarece cheile secrete pentru toți utilizatorii sunt stocate pe serverul central, o compromitere a serverului va compromite cheile secrete ale tuturor utilizatorilor.
• Un client compromis va compromite parola utilizatorului.

Pagini conexe

• Managementul identității
• Protocol securizat de parolă la distanță (SRP)
• Interfața de program de aplicație pentru serviciile de securitate generice (GSS-API)