Explica-mi ca eu sunt de 5 ani: Kerberos – ce este Kerberos, și de ce ar trebui să îmi pese?în timp ce acest subiect, probabil, nu poate fi explicat la un 5 ani și să fie înțeles, aceasta este încercarea mea de a defragmentarea documentare cu unele ajutoare vizuale și limbaj digerabil.,
Într-un cuvânt
de Fapt, Kerberos se reduce la asta:
- un protocol de autentificare
- foloseste bilete pentru autentificarea
- evită stocarea parole la nivel local sau le trimite prin internet
- implică o încredere 3rd-party
- construit pe criptografie cu chei simetrice
Ai un bilet – dovada de identitate criptate cu o cheie secretă pentru un anumit serviciu solicitat – pe computerul local (crearea unui bilet este descris mai jos); atât timp cât este valabil, puteți accesa serviciul solicitat, care este într-o Kerberos tărâm.,
De obicei, acest lucru este utilizat în mediile corporative / interne. Poate că doriți să accesați site-ul dvs. intern de salarizare pentru a examina ce mic bonus ți-a oferit șeful tău. În loc să reintroduceți acreditările de utilizator/parolă, biletul dvs. (memorat în cache pe sistemul dvs.) este utilizat pentru a vă autentifica, permițând o singură conectare.
biletul dvs. este actualizat când vă conectați la computer sau când kinit USER în terminalul dvs.pentru oamenii iubitori de trivia, numele lui Kerberos provine din mitologia greacă, câinele de pază cu trei capete al lui Hades., Este destul de potrivit, deoarece este nevoie de o terță parte (un centru de distribuție a cheilor) pentru a se autentifica între un client și un serviciu sau o mașină gazdă.
Kerberos Tărâmul
Admini crea regiuni – Kerberos tărâmuri – care va cuprinde tot ceea ce este disponibil pentru a accesa. Acordat, este posibil să nu aveți acces la anumite servicii sau mașini gazdă care sunt definite în cadrul gestionării politicilor – dezvoltatorii nu ar trebui să acceseze nimic legat de Finanțe, chestii de genul acesta. Dar un tărâm definește ce gestionează Kerberos în ceea ce privește cine poate accesa ce.,
mașina dvs., clientul, trăiește în acest domeniu, precum și serviciul sau gazda pe care doriți să o solicitați și Centrul de distribuție a cheilor, KDC (nu, nu KGB, deși mă gândesc mereu la asta). În exemplul următor, separez serverul de autentificare și serverul de acordare a biletelor, dar ambele sunt în cadrul KDC.
pentru a vă păstra în minte
poate doriți să reveniți aici după ce ați citit detaliile despre cum funcționează exemplul.,când solicitați acces la un serviciu sau gazdă, au loc trei interacțiuni între dvs. și:
- serverul de autentificare
- serverul de acordare a biletelor
- serviciul sau mașina gazdă la care doriți accesul.alte puncte importante:
- Cu fiecare interacțiune, veți primi două mesaje. Fiecare mesaj este unul pe care îl puteți decripta și unul pe care nu îl puteți.
- serviciul sau mașina la care solicitați acces nu comunică niciodată direct cu KDC.,
- KDC stochează toate cheile secrete pentru mașinile și serviciile utilizatorilor în baza sa de date.
- cheile secrete sunt parole, plus o sare care sunt hashed-algoritmul hash este ales în timpul implementării configurației Kerberos. Pentru servicii sau mașini gazdă, nu există parole (cine le-ar introduce). O cheie este de fapt generată de un administrator în timpul configurării inițiale și memorată pe mașina de serviciu/gazdă.
- din nou, aceste chei secrete sunt toate stocate în baza de date KDC; amintesc dependența lui Kerberos de criptografia cu chei simetrice.,
- KDC în sine este criptat cu o cheie master pentru a adăuga un strat de dificultate de a fura cheile din Baza de date.
- există configurații și implementări Kerberos care utilizează criptografia cu cheie publică în loc de criptarea simetrică a cheilor.
o parte: ordinea mesajelor și conținutul lor discutate aici nu reflectă ordinea în care sunt trimise prin TCP sau UDP.
exemplul de mai jos descrie ce se întâmplă atunci când solicitați ceva de la un serviciu HTTP intern – cum ar fi informații privind salarizarea din intranetul corporativ.,
Tu și serverul de autentificare
doriți să accesați un serviciu HTTP, dar mai întâi trebuie să vă prezentați la serverul de autentificare. Logarea în computer, sau
kinit USERNAME, inițiază această introducere printr-o cerere de text clar pentru un bilet de acordare bilet (TGT)., Plaintext mesaj contine:- numele/ID
- numele/ID-ul de serviciul solicitat (în acest caz, serviciul este Biletul de Acordare Server),
- adresa de rețea (poate fi o listă de adrese IP pentru mai multe masini, sau poate fi nulă în cazul în care doresc să folosească pe orice mașină), și
- a solicitat viață pentru validitatea TGT,
și este trimis la Serverul de Autentificare.
serverul de autentificare va verifica dacă vă aflați în baza de date KDC. Această verificare este doar pentru a vedea dacă există; nu sunt verificate acreditările.,
Dacă nu există erori (de exemplu, utilizatorul nu este găsit), se va genera aleatoriu o cheie numit o cheie de sesiune pentru utilizarea între tine și Bilet de Acordare Server (TGS).
serverul de autentificare va trimite apoi două mesaje înapoi la tine., Un mesaj este TGT care conține:
- numele/ID-ul,
- TGS numele/ID-ul,
- timestamp,
- adresa de rețea (poate fi o listă de adrese IP pentru mai multe masini, sau poate fi nulă în cazul în care doresc să folosească pe orice mașină)
- durata de viata a TGT (ar putea fi ceea ce ai solicitat inițial, mai mici sau TGS e chei secrete sunt pe cale să expire, sau o altă limită care a fost implementat în Kerberos setup), și
- TGS Cheie de Sesiune,
și este criptat cu TGS Cheie Secretă ., Celălalt mesaj conține:
- TGS name/ID,
- timestamp,
- lifetime (la fel ca mai sus) și
- TGS Session Key
și este criptat cu cheia secretă a clientului. Rețineți că cheia sesiunii TGS este cheia partajată între dvs. și TGS.cheia secretă a clientului dvs. este determinată prin solicitarea parolei dvs., adăugarea unei sare (formată din
) și hashing totul. Acum îl puteți folosi pentru decriptarea celui de-al doilea mesaj pentru a obține cheia sesiunii TGS., Dacă parola este incorectă, atunci nu veți putea decripta mesajul. Vă rugăm să rețineți că acesta este pasul în care parola pe care o introduceți este validată implicit.
cu toate acestea, nu puteți decripta TGT deoarece nu cunoașteți cheia secretă TGS. TGT criptat este stocat în memoria cache de acreditare.
Tu și serverul de acordare a biletelor
în acest moment, aveți TGT-ul pe care nu îl puteți citi, deoarece nu aveți cheia secretă TGS pentru a-l decripta. Cu toate acestea, aveți cheia sesiunii TGS.,acum este rândul tău să trimiți două mesaje. Mai întâi pregătiți autentificatorul, criptat cu cheia sesiunii TGS, care conține:
- numele / ID-ul dvs. și
- marca de timp.
trimiteți un mesaj necriptat care conține:
- numele/ID-ul Serviciului HTTP solicitat la care doriți să accesați și
- durata de viață a biletului pentru serviciul HTTP,
împreună cu autentificatorul criptat și TGT la serverul de acordare a biletelor.
serverul de acordare a biletelor va verifica mai întâi baza de date KDC pentru a vedea dacă există serviciul HTTP.,
dacă da, TGS decriptează TGT cu cheia sa secretă . Deoarece TGT-ul acum necriptat conține cheia sesiunii TGS, TGS poate decripta autentificatorul pe care l-ați trimis.,datorită:
- compara ID-ul de client de la Authenticator pentru că a TGT
- compara timestamp din Authenticator pentru că a TGT (tipic Kerberos-sistem de toleranță din diferența este de 2 minute, dar poate fi configurat altfel)
- verificați pentru a vedea dacă TGT este expirat (durata element),
- verificați că Authenticator nu este deja în TGS cache (pentru a evita atacurile de reluare), și
- dacă adresa de rețea în cererea inițială nu este null, compară sursă adresa IP la adresa de rețea (sau în termen de cel solicitat lista) în TGT.,
Bilet de Acordare Server apoi generează aleatoriu Serviciul HTTP Cheie de Sesiune, și pregătește HTTP Serviciu de vânzare bilete pentru tine, care conține:
- numele/ID-ul,
- HTTP Service name/ID,
- adresa de rețea (poate fi o listă de adrese IP pentru mai multe masini, sau poate fi nulă în cazul în care doresc să folosească pe orice masina),
- timestamp,
- durata de valabilitate a biletului, și
- HTTP Servicii Cheie de Sesiune,
și criptează cu Serviciul HTTP Cheie Secretă.
apoi TGS vă trimite două mesaje., Unul este tichetul de serviciu HTTP criptat; celălalt conține:
- HTTP Service name / ID,
- timestamp,
- durata de viață a valabilității biletului și
- HTTP Service Session Key,
care este criptat cu tasta de sesiune TGS.
aparatul dvs. decriptează ultimul mesaj cu tasta de sesiune TGS pe care a memorat-o în cache mai devreme pentru a obține cheia de sesiune a serviciului HTTP.cu toate acestea, aparatul dvs. nu poate decripta biletul de serviciu HTTP, deoarece este criptat cu cheia secretă a serviciului HTTP.,
Ai și Serviciul HTTP
Pentru a accesa acum HTTP Service, aparatul se pregătește un alt Authenticator mesaj care conține:
- numele/ID-ul,
- timestamp,
și este criptat cu Serviciul HTTP Cheie de Sesiune. Aparatul dvs. trimite apoi autentificatorul și biletul de serviciu HTTP încă criptat primit de la TGS.
serviciul HTTP decriptează apoi biletul cu cheia secretă pentru a obține cheia de sesiune a serviciului HTTP., Apoi folosește acea cheie de sesiune pentru a decripta mesajul autentificator pe care l-ați trimis.,es ID-ul de client de Autentificare a acelui Bilet,
- compară timestamp din Authenticator pentru că a Biletului (tipic Kerberos-sistem de toleranță din diferența este de 2 minute, dar poate fi configurat altfel),
- controale pentru a vedea dacă Biletul este expirat (durata element),
- verificarea de Autentificare nu este deja în HTTP Server de cache (pentru a evita atacurile de reluare), și
- dacă adresa de rețea în cererea inițială nu este null, compară sursă adresa IP la adresa de rețea (sau în termen de cel solicitat lista) în Bilet.,
serviciul HTTP trimite apoi un mesaj de autentificare care conține ID-ul și marcajul de timp pentru a vă confirma identitatea și este criptat cu cheia de sesiune a serviciului HTTP.
aparatul citește Authenticator mesaj de mar cu HTTP cache Servicii Cheie de Sesiune, și știe că trebuie să primească un mesaj cu Serviciul HTTP ID-ul și timestamp.
și acum ați fost autentificat pentru a utiliza serviciul HTTP., Cererile viitoare utilizează biletul de serviciu HTTP din cache, atât timp cât nu a expirat așa cum este definit în atributul lifetime.
în timp ce voi scrie mai târziu, serviciul HTTP în sine trebuie să poată suporta Kerberos. De asemenea, trebuie să aveți și un browser care acceptă SPNEGO/Negotiate.,
poate recitiți punctele prezentate anterior; verificați această sau această implementare curentă, în special cea pe care sunt plătit să lucrez care comunică cu această implementare Populară; sau revizuiți un tutorial, ghid de resurse, videoclipul care mi-a fost trimis când am început să învăț despre Kerberos sau RFC în sine.
imaginile de mai sus au fost redate cu Keynote cu pictograme folosite de Font awesome și glyphicons, și sunt disponibile pe slideshare.