Kerberos

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 21. marts 2020; verifikation kræver 21 redigeringer .

Kerberos /kɛərbərəs/ er en netværksgodkendelsesprotokol , der tilbyder en mekanisme til gensidig godkendelse af en klient og server, før der etableres en forbindelse mellem dem. Kerberos udfører godkendelse som en betroet tredjepartsgodkendelsestjeneste ved hjælp af en kryptografisk delt hemmelighed, forudsat at pakker, der rejser over et usikkert netværk, kan opsnappes, ændres og bruges af en angriber. Kerberos er bygget på symmetrisk nøglekryptografi og kræver et nøgledistributionscenter. Kerberos-udvidelser kan give brug af offentlig nøglekryptering i visse godkendelsestrin.

Oprettelseshistorie

Den første version af Kerberos-protokollen blev oprettet i 1983 på Massachusetts Institute of Technology (MIT) som en del af Athena-projektet.. Hovedmålet med projektet var at udvikle en plan for introduktion af computere i MIT uddannelsesprocessen og relateret software. Projektet var lærerigt, men slutresultatet omfattede adskillige softwareprodukter, som stadig er meget udbredt i dag (såsom X Window System ). Denne protokol er blevet offentligt tilgængelig siden version 4.

Grundlæggende begreber

Lad os skitsere det grundlæggende koncept for Kerberos-protokollen. Antag, at der er to mennesker, der kender den samme hemmelighed, kun kendt af disse to. Så kan enhver af dem sagtens være sikker på, at han har med sin partner at gøre. For at gøre dette skal han bare tjekke, om hans samtalepartner kender den fælles hemmelighed.

Eksempel.

Punkt 1. Aftale om adgangskoden. Lad Alice kommunikere med Bob. I dette tilfælde bruger Bob kun oplysningerne, når han er sikker på, at oplysningerne er modtaget fra Alice. For at undgå forfalskning aftalte de indbyrdes et kodeord, som kun de to kender. Når han modtager en besked, kan Bob ud fra brevet konkludere, om hans samtalepartner kender adgangskoden. Hvis Bobs samtalepartner kender adgangskoden, så kan det argumenteres for, at hans samtalepartner er Alice.

Punkt 2. Forekomsten af ​​et problem med adgangskodetransmission. Lad os nu bestemme, hvordan man viser Alice og Bob viden om adgangskoden. Du kan selvfølgelig blot inkludere adgangskoden i e-mailens brødtekst. For eksempel: "Hej Bob. Vores adgangskode. Hvis kun Bob og Alice var sikre på, at ingen læser deres breve, så kunne denne metode bruges. Men desværre sendes mailen over et netværk, hvor andre brugere arbejder, blandt hvilke der er en nysgerrig Eva. Eve satte sig selv til opgave at finde ud af adgangskoden, kun kendt af Bob og Alice, som de udveksler beskeder med hinanden med. Nu er det helt klart, at du ikke kan angive adgangskoden blot i brødteksten. Det betyder, at du ikke kan tale åbent om adgangskoden, men du skal samtidig give samtalepartneren besked om, at du kender adgangskoden.

Punkt 3. Løsning af problemet med adgangskodeoverførsel. Kerberos-protokollen løser problemet med adgangskodetransmission ved hjælp af hemmelig nøglekryptering. I stedet for at fortælle hinanden et kodeord, udveksler deltagerne i en kommunikationssession en kryptografisk nøgle, hvis viden bekræfter samtalepartnerens identitet. Men for at en sådan teknologi skal være mulig, er det nødvendigt, at den delte nøgle er symmetrisk , det vil sige, at nøglen skal sørge for både kryptering og dekryptering af beskeden.

Punkt 4. Problemet med adgangskodeudveksling. Der er et vigtigt problem, når du bruger simple protokoller som den, der er beskrevet ovenfor. I tilfældet med Bob og Alice skal du forstå, hvordan de bliver enige om en hemmelig nøgle til at korrespondere med hinanden. Selvfølgelig kan folk mødes og blive enige, men maskiner deltager også i netværksforhandlinger. Hvis Alice forstås som et klientprogram, og Bob er en tjeneste på en netværksserver, så kan de ikke mødes på nogen måde. Problemet er, at når en klient skal sende en besked til flere servere, skal den i dette tilfælde anskaffe en separat nøgle for hver server. Og så skal serveren bruge lige så mange hemmelige nøgler, som den har klienter. Behovet for at gemme så mange nøgler på hver computer udgør en risiko for hele sikkerhedssystemet.

Punkt 5. Løsning af problemet med udveksling af adgangskoder. For at løse disse problemer udviklede Athena-projektet en særlig protokol - Kerberos. I analogi med oldgræsk mytologi blev denne protokol opkaldt efter den trehovedede hund, der beskyttede udgangen fra Hades -kongeriget - Cerberus , eller mere præcist - Cerberus. De tre hoveder af Cerberus i protokollen svarer til tre deltagere i sikker kommunikation: en klient, en server og en betroet mellemmand mellem dem. Mellemmandens rolle her spilles af Nøgledistributionscenteret, KDC.

Nøgledistributionscenter KDC (eller TGS - billet- eller tilladelsesserver)

Et nøgledistributionscenter (KDC) er en tjeneste, der kører på en fysisk sikker server. Centret fører en database med oplysninger om konti for alle netværksklienter. Sammen med information om hver abonnent lagrer nøgledistributionscenterets database en kryptografisk nøgle, som kun er kendt af denne abonnent og centertjenesten. Denne nøgle bruges til at forbinde klienten med centeret.

Klient til server gennem KDC

Hvis klienten ønsker at kontakte serveren, sender han en besked til nøgledistributionscentret. Centret sender til hver sessionsdeltager kopier af sessionsnøglen, der er gyldig i en kort periode. Formålet med disse nøgler er at autentificere klienten og serveren. En kopi af sessionsnøglen, der sendes til serveren, krypteres ved hjælp af serverens langtidsnøgle, og sendt til klienten krypteres med klientens langtidsnøgle. For at udføre funktionerne som en betroet mellemmand teoretisk set er det nok for et nøgledistributionscenter at sende sessionsnøgler direkte til sikkerhedsabonnenter. Det er dog yderst vanskeligt at gennemføre en sådan ordning i praksis. Derfor bruges der i praksis en anden adgangskodestyringsordning, som gør Kerberos-protokollen meget mere effektiv.

Sessionsbilletter

Som svar på en anmodning fra en klient, der har til hensigt at oprette forbindelse til serveren, sender KDC-tjenesten begge kopier af sessionsnøglen til klienten. Meddelelsen, der er bestemt til klienten, er krypteret med en langtidsnøgle, der deles mellem klienten og KDC, og sessionsnøglen til serveren, sammen med information om klienten, er indlejret i en datablok kaldet en sessionsbillet. Hele sessionsbilletten krypteres derefter med en langtidsnøgle, som kun KDC-tjenesten og denne server kender. Herefter ligger alt ansvar for at behandle billetten, som bærer den krypterede sessionsnøgle, hos klienten, som skal levere den til serveren. Ved modtagelse af KDC-svaret udtrækker klienten billetten og dens kopi af sessionsnøglen fra den, som den placerer i sikker lagring (den er ikke placeret på disken, men i RAM ). Når den skal kontakte en server, sender klienten den en besked, der består af en billet, der stadig er krypteret med serverens langtidsnøgle, og dens egen autentificering, krypteret med sessionsnøglen. Denne legitimationsoplysninger, kombineret med godkendelsesværktøjet, udgør den legitimationsoplysninger, hvormed serveren bestemmer klientens "identitet". Efter at have modtaget klientens "identitetskort" dekrypterer serveren først og fremmest sin hemmelige nøgle sessionsbilletten og udtrækker sessionsnøglen fra den, som den derefter bruger til at dekryptere klientautentificeringsværktøjet. Hvis alt går godt, konkluderes det, at klientidentiteten er udstedt af en betroet mellemmand, det vil sige af KDC-tjenesten. Klienten kan kræve, at serveren udfører gensidig godkendelse. I dette tilfælde krypterer serveren, ved hjælp af sin kopi af sessionsnøglen, tidsstemplet fra klientens autentificering og sender det til klienten som sin egen autentificering. En fordel ved at bruge sessionslegitimationsoplysninger er, at serveren ikke behøver at gemme sessionsnøgler for at kommunikere med klienter. De gemmes i klientens "credentials cache", som videresender billetten til serveren, hver gang den ønsker at kontakte den. Serveren på sin side, efter at have modtaget billetten fra klienten, dekrypterer den og udtrækker sessionsnøglen. Når nøglen ikke længere er nødvendig, kan serveren blot slette den fra sin hukommelse. Denne metode har en anden fordel: klienten behøver ikke at kontakte KDC før hver session med en bestemt server. Sessionslegitimationsoplysninger kan genbruges. I tilfælde af deres tyveri indstilles udløbsdatoen for billetten, som KDC angiver i selve datastrukturen. Dette tidspunkt bestemmes af den rigesspecifikke Kerberos-politik. Typisk overstiger gyldighedsperioden for billetter ikke otte timer, det vil sige standardvarigheden af ​​en session i netværket. Når en bruger logger ud, nulstilles legitimationscachen, og alle sessionslegitimationsoplysninger, sammen med sessionsnøgler, bliver ødelagt.

Protokoludvikling

Tidlige versioner

MIT udviklede Kerberos til at sikre netværkstjenester leveret af Athena-projektet. Protokollen blev opkaldt efter den græske mytologiske karakter Kerberos (eller Cerberus ), kendt i græsk mytologi som den monstrøse trehovedede vagthund Hades. Der er flere versioner af protokollen. Tidlige versioner af Kerberos (1 til 3) blev oprettet internt af MIT og brugt til testformål. Disse implementeringer indeholdt betydelige begrænsninger og var kun nyttige til at udforske nye ideer og identificere problemer, der kunne opstå under udvikling.

Steve Miller og Clifford Neuman , hoveddesignerne af Kerberos version 4 (som brugte DES-krypteringsalgoritmen med 56-bit nøgler), udgav denne version i 1989, selvom de stadig primært planlagde den på det tidspunkt i Athena-projektet.

Kerberos 4

Kerberos 4 blev første gang udgivet den 24. januar 1989 . Det var den første version, der blev distribueret uden for MIT, forberedt til, at flere leverandører kunne inkludere den i deres operativsystemer. Derudover brugte andre store distribuerede systemprojekter (for eksempel Andrew File System ) ideerne fra Kerberos 4 til deres godkendelsessystemer.

Grundlaget for det, der skulle blive Kerberos 4, blev beskrevet i Athena whitepaper [1] , og den endelige version blev fastgjort i kildekoden til referenceimplementeringen udgivet af MIT.

Men på grund af amerikanske regerings restriktioner på eksport af krypteret software, kunne Kerberos 4 ikke distribueres uden for USA. Da Kerberos 4 brugte DES -algoritmen til kryptering , kunne organisationer uden for USA ikke lovligt bruge softwaren. Som svar oprettede MIT-udviklingsteamet en speciel version af Kerberos 4, der ekskluderede al kode relateret til kryptering fra den. Disse foranstaltninger gjorde det muligt at omgå eksportrestriktionen.

Senere tilføjede Errol Young ved Bond University of Australia sin egen implementering af DES til denne udgivelse. Det blev kaldt "E-Bones" (forkortelse for "encrypted bones" [2] ) og var gratis at distribuere uden for USA.

I 2006 blev understøttelse af Kerberos 4 annonceret [3] .

Kerberos 5

For at overvinde sikkerhedsproblemerne i den tidligere version udviklede John Kohl og Clifford Neuman version 5 af protokollen, som blev offentliggjort i 1993 i RFC 1510 . Over tid, i 2005, begyndte IETF Kerberos arbejdsgruppe at behandle specifikationen. Dokumenter, de har offentliggjort, omfatter:

I juni 2006 blev RFC 4556 introduceret , der beskriver en udvidelse til version 5 kaldet PKINIT ( offentlig nøglekryptografi  til initial godkendelse i Kerberos ) . Denne RFC beskrev, hvordan man bruger asymmetrisk kryptering under klientgodkendelsesfasen .

Året efter (2007) dannede MIT Kerberos-konsortiet for at fremme yderligere udvikling.

Brug og distribution

Distribution af Kerberos-implementeringen sker under copyright, svarende til BSD-rettigheder.

I øjeblikket understøtter mange operativsystemer denne protokol, herunder:

Sådan virker det

Kerberos 4

Kerberos 4 er stort set baseret på Needham-Schroeder- protokollen , men med to væsentlige ændringer.

Som et resultat indeholder Kerberos 4-protokollen to logiske komponenter:

Typisk leveres disse komponenter som et enkelt program, der kører på et nøgledistributionscenter (KDC - indeholder en database med logins/adgangskoder til brugere og tjenester, der bruger Kerberos).

Godkendelsesserveren udfører én funktion: den modtager en anmodning, der indeholder navnet på den klient, der anmoder om godkendelse, og returnerer til den en krypteret billet for at få en billet (TGT). Brugeren kan derefter bruge denne billet til at anmode om efterfølgende billetter til andre tjenester. I de fleste Kerberos-implementeringer er TGT-levetiden 8-10 timer. Derefter skal klienten igen anmode om det fra godkendelsesserveren.

Den første besked, der sendes til nøgledistributionscentret, er en anmodning til godkendelsesserveren, også kendt som AS_REQ. Denne besked sendes i klartekst og indeholder klientens identitet, klientens tidsstempel og ticket-granting server (TGS) identifikator.

Når nøgledistributionscentret modtager en AS_REQ-meddelelse, tjekker det, at den klient, som anmodningen kom fra, eksisterer, og dens tidsstempling er tæt på centrets lokale tid (normalt ± 5 minutter). Denne kontrol er ikke lavet for at beskytte mod gentagelser (beskeden sendes i klartekst), men for at tjekke timingen. Hvis mindst en af ​​kontrollerne mislykkes, sendes en fejlmeddelelse til klienten, og den godkendes ikke.

Hvis det lykkes, genererer godkendelsesserveren en tilfældig sessionsnøgle, der vil blive delt mellem klienten og billet- eller tildelingsserveren (denne nøgle beskytter fremtidige billetanmodninger til andre tjenester). Nøgledistributionscentret opretter 2 kopier af sessionsnøglen: en til klienten og en til den billetbevilgende server.

Nøgledistributionscentret svarer derefter til klienten med en godkendelsesservermeddelelse (AS_REP) krypteret med klientens langtidsnøgle. Denne meddelelse inkluderer TGT, der er krypteret med TGS-nøglen, en kopi af sessionsnøglen for klienten, billettens levetid og TGS-id'et (TGT indeholder: en kopi af sessionsnøglen til TGS'en, klient-id'et, billettens levetid, Key Distribution Center (KDC) tidsstempel, IP-adresseklient).

Når brugeren ønsker at få adgang til tjenesten, vil han forberede en besked til TGS_REQ indeholdende 3 dele: tjeneste-id'en, kopien af ​​TGT modtaget tidligere, og godkendelsesværktøjet (godkendelsesværktøjet består af et tidsstempel krypteret med sessionsnøglen modtaget fra autentificeringsserver og tjener til at beskytte mod gentagelser).

Ved modtagelse af en billetanmodning fra en klient genererer KDC en ny sessionsnøgle til klient/tjeneste-interaktionen. Den sender derefter en svarmeddelelse (TGS_REP) krypteret med sessionsnøglen modtaget fra godkendelsesserveren. Denne meddelelse indeholder den nye sessionsnøgle, servicebillet krypteret med den langsigtede servicenøgle, service-id og billetlevetid (indeholder en kopi af den nye sessionsnøgle, klient-id, billetlevetid, nøgledistributionscenter lokal tid, klientens IP-adresse ).

Detaljerne i det sidste trin, at sende servicebilletten til applikationsserveren, er ikke standardiseret af Kerberos 4, så implementeringen er fuldstændig applikationsafhængig.

Kerberos 5

Kerberos 5 er en udvikling af den fjerde version, indeholder al den tidligere funktionalitet og indeholder mange udvidelser. Men fra et implementeringssynspunkt er Kerberos 5 en helt ny protokol.

Hovedårsagen til udseendet af den femte version var umuligheden af ​​udvidelse. Med tiden blev et brute-force angreb på DES brugt i Kerberos 4 relevant, men felterne brugt i beskeder havde en fast størrelse, og det var ikke muligt at bruge en stærkere krypteringsalgoritme.

For at løse dette problem blev det besluttet at skabe en udvidelig protokol, der kan bruges på forskellige platforme baseret på ASN.1 teknologi. Dette gjorde det muligt at bruge forskellige typer kryptering i transaktioner. Takket være dette blev kompatibilitet med den tidligere version implementeret. Derudover har KDC mulighed for at vælge den sikreste krypteringsprotokol, der understøttes af de deltagende parter.

Derudover er den originale Kerberos 4-protokol underlagt ordbogsoptælling. Denne sårbarhed er relateret til det faktum, at KDC udsteder en krypteret TGT på efterspørgsel til enhver klient. Vigtigheden af ​​dette problem understreges også af det faktum, at brugere normalt vælger simple adgangskoder.

For at gøre dette angreb vanskeligere introducerede Kerberos 5 præ-godkendelse. På dette stadium kræver KDC, at brugeren bekræfter deres identitet, før de kan få udstedt en billet.

KDC-politikken er ansvarlig for forhåndsgodkendelse, hvis det er påkrævet, vil brugeren modtage en KRB_ERROR-meddelelse på den første anmodning til godkendelsesserveren. Denne meddelelse vil bede klienten om at sende en AS_REQ-anmodning med deres legitimationsoplysninger for at godkende. Hvis KDC ikke genkender dem, vil brugeren modtage endnu en KRB_ERROR-meddelelse, der indikerer en fejl, og der vil ikke blive udstedt nogen TGT.

Formel beskrivelse Kryptografiske notationer, der bruges i godkendelses- og nøgleudvekslingsprotokoller
Identifikatorer for Alice ( Alice ), initiativtageren til sessionen
Identifikator for Bob ( Bob ), den side, hvorfra sessionen er etableret
Identifikator for Trent ( Trent ), en betroet mellempart
Alice, Bob og Trents offentlige nøgler
Alice, Bob og Trents hemmelige nøgler
Kryptering af data med Alices nøgle, eller Alice og Trents fælles nøgle
Kryptering af data med Bobs nøgle eller Bob og Trents fælles nøgle
Datakryptering med hemmelige nøgler af Alice, Bob (digital signatur)
Sessionssekvensnummer (for at forhindre gentagelsesangreb)
Tilfældig sessionsnøgle, der skal bruges til symmetrisk datakryptering
Kryptering af data med en midlertidig sessionsnøgle
Tidsstempler føjet til beskeder af henholdsvis Alice og Bob
Tilfældige tal ( nonce ), der blev valgt af henholdsvis Alice og Bob

Protokollen bruger kun symmetrisk kryptering og antager, at hver korrespondent (Alice og Bob) deler en hemmelig nøgle med en betroet tredjepart (Trent).

Alice sender sit ID og Bob til den betroede part (Trent):

Trent genererer to beskeder. Den første inkluderer tidsstemplet , nøglens levetid , den nye sessionsnøgle for Alice og Bob og Bobs ID . Denne besked er krypteret med Alice og Trents delte nøgle. Den anden besked indeholder det samme, bortset fra identifikatoren - den er blevet erstattet med Alices identifikator . Selve beskeden er krypteret med Trent og Bobs delte nøgle:

Alice genererer en besked fra sit eget ID og et tidsstempel , og krypterer derefter beskeden med sessionsnøglen og sender den til Bob sammen med den anden besked fra Trent:

Til sin egen autentificering krypterer Bob det ændrede tidsstempel med en delt sessionsnøgle og sender det til Alice:

En vigtig antagelse er, at alle protokoldeltageres ure er synkroniserede. Men i praksis bruges synkronisering med en nøjagtighed på flere minutter, hvor transmissionshistorikken er gemt (for at detektere gentagelser) i nogen tid.

Detaljeret beskrivelse

Den måde, Kerberos 5 i øjeblikket fungerer på, er som følger:

Brugerlogin:

  1. Brugeren indtaster et brugernavn og en adgangskode på klientmaskinen.
  2. Klientmaskinen udfører en envejsfunktion (normalt en hash) på adgangskoden, og resultatet bliver klientens/brugerens hemmelige nøgle.

Klientgodkendelse:

  1. Klienten sender en anmodning (AS_REQ) til CA'en om at få godkendelsesoplysninger og derefter give dem til TGS-serveren (senere vil den bruge dem til at opnå legitimationsoplysninger uden yderligere anmodninger om at bruge brugerens private nøgle). Denne anmodning indeholder:
    • Klient-id'et, dets tidsstempel og server-id'et.
  2. Hvis KDC-politikken kræver præ-godkendelse, så modtager brugeren en KRB_ERROR-meddelelse, som svar på hvilken han sender en anden anmodning, men med godkendelsesdata.
  3. CA kontrollerer, om der er en sådan klient i databasen. Hvis det er tilfældet, sender CA en meddelelse tilbage (AS_REP), inklusive:
    • Klientens sessionsnøgle eller TGS, TGS identifikatoren og billettens levetid , krypteret med klientens private nøgle .
    • TGT (som inkluderer klient-id og netværksadresse, KDC-tidsstempel, billetgyldighedsperiode og klientsessionsnøgle eller TGS) krypteret med den hemmelige TGS-nøgle.

Hvis ikke, modtager klienten en ny besked, der indikerer, at der er opstået en fejl.

  1. Ved modtagelse af meddelelsen dekrypterer klienten sin del for at opnå klientens sessionsnøgle eller TGS. Denne sessionsnøgle bruges til yderligere udveksling med TGS-serveren. (Vigtigt: Klienten kan ikke dekryptere TGT, fordi den er krypteret med TGS hemmelige nøgle) På dette tidspunkt har brugeren nok legitimationsoplysninger til at logge på TGS.

Kundeautorisation på TGS:

  1. For at anmode om en tjeneste genererer klienten en anmodning om TGS (TGS_REQ) indeholdende følgende data:
    • TGT modtaget tidligere og service-id.
    • En autentificering (sammensat af et klient-id og et tidsstempel) krypteret på klient-/TGS-sessionsnøglen.
  2. Ved modtagelse af TGS_REQ uddrager TGS TGT'en fra den og dekrypterer den ved hjælp af den hemmelige TGS-nøgle. Dette giver ham klientens sessionsnøgle eller TGS. Med den dekrypterer han autentificeringen. Den genererer derefter en klient-/servicesessionsnøgle og sender et svar (TGS_REP) inklusive:
    • servicebillet (som indeholder klient-id, klientnetværksadresse, KDC-tidsstempel, billetudløbstid og klient/service-sessionsnøgle) krypteret med tjenestens hemmelige nøgle.
    • Klient-/servicesessionsnøglen, service-id og billetlevetid krypteret på klient-/TGS-sessionsnøglen.

Serviceanmodning fra klient:

  1. Efter at have modtaget TGS_REP, har klienten nok information til at godkende tjenesten. Klienten opretter forbindelse til den og sender en besked, der indeholder:
    • Den krypterede tjenestebillet modtaget tidligere.
    • En ny godkendelse krypteret med klient-/tjenestesessionsnøglen og inklusive klient-id og tidsstempel.
  2. Tjenesten dekrypterer billetten ved hjælp af dens private nøgle og henter klient-/servicesessionsnøglen. Ved at bruge den nye nøgle dekrypterer den autentificeringen og sender følgende besked til klienten for at bekræfte, at den er klar til at betjene klienten, og at serveren virkelig er den, den hævder at være:
    • Tidsstemplet angivet af klienten + 1 , krypteret med klient-/tjenestesessionsnøglen.
  3. Klienten dekrypterer bekræftelsen ved hjælp af klient-/servicesessionsnøglen og kontrollerer, at tidsstemplet faktisk er blevet opdateret korrekt. Hvis det er tilfældet, kan klienten stole på serveren og kan begynde at sende anmodninger til serveren.
  4. Serveren giver klienten den nødvendige service.

PKINIT

PKINIT-udvidelsen påvirkede klientens præ-autentificeringsstadium, hvorefter det begyndte at ske som følger:

  1. Brugeren identificeres i systemet og præsenterer sin private nøgle.
  2. Klientmaskinen udsteder en anmodning til CA (AS_REQ), der angiver, at asymmetrisk kryptering vil blive brugt. Forskellen på denne anmodning er, at den er signeret (ved hjælp af klientens private nøgle) og, udover standardoplysningerne, indeholder brugerens offentlige nøglecertifikat.
  3. Ved modtagelse af anmodningen verificerer KDC først gyldigheden af ​​brugerens certifikat og derefter den digitale signatur (ved hjælp af brugerens offentlige nøgle modtaget) . Derefter kontrollerer KDC den lokale tid sendt i anmodningen (for at beskytte mod gentagelser) .
  4. Efter at have verificeret ægtheden af ​​klienten, genererer KDC et svar (AS_REP), hvor sessionsnøglen i modsætning til standardversionen krypteres med brugerens offentlige nøgle. Derudover indeholder svaret KDC-certifikatet og er signeret med dets private nøgle (svarende til klientens anmodning) .
  5. Efter at have modtaget svaret, verificerer brugeren KDC's signatur og dekrypterer deres sessionsnøgle (ved hjælp af deres private) .

Yderligere trin sker i henhold til standardbeskrivelsen af ​​Kerberos V5.

Ulemper og begrænsninger

  • Single point of failure: Kræver en central server til enhver tid. Når Kerberos-serveren går ned, kan nye brugere ikke logge på. Dette kan rettes med flere Kerberos-servere og fallback-godkendelsesmekanismer.
  • Kerberos har strenge tidskrav, hvilket betyder, at deltagernes ure skal holdes synkroniseret inden for specificerede grænser. Legitimationsoplysningerne har en levetid, og hvis klientens ur ikke er synkroniseret med Kerberos-serverens ur, vil godkendelsen mislykkes. Standardkonfigurationen kræver, at urene ikke er mere end fem minutter fra hinanden. I praksis bruges Network Time Protocol-dæmoner typisk til at synkronisere ure på klienter.
  • Administrationsprotokollen er ikke standardiseret og afhænger af den specifikke serverimplementering. Adgangskodeændring er beskrevet i RFC 3244.
  • I tilfælde af symmetrisk kryptografi (Kerberos kan arbejde med både symmetrisk og asymmetrisk (offentlig nøgle) kryptografi), da alle autentificeringsmetoder administreres centralt af nøgledistributionscentret (KDC), vil denne funktion i godkendelsesinfrastrukturen tillade en angriber at efterligne en bruger.
  • Hver netværkstjeneste, der kræver en ændring af værtsnavnet, skal opdatere sit eget sæt Kerberos-nøgler. Dette komplicerer brugen af ​​delt hosting og klynger.
  • Kerberos kræver, at brugerkonti, klienter og tjenestebrugere på serveren alle har tillid til Kerberos-serveren (alle skal være i det samme domæne med Kerberos eller i domæner, der har et tillidsforhold til hinanden). Kerberos kan ikke bruges i tilfælde, hvor brugere ønsker at oprette forbindelse til tjenester fra ukendte/ikke-pålidelige klienter, som på det almindelige internet.

Sårbarheder

DES-chifferet kan bruges med Kerberos, men det er ikke længere en internetstandard, fordi det er sårbart. Der findes imidlertid sårbarheder i mange produkter, der bruger Kerberos, som ikke er blevet opdateret til at erstatte DES med nyere cifre, såsom AES for eksempel.

I november 2014 udgav Microsoft en patch (MS14-068) for at rette en sårbarhed i Windows-implementeringen af ​​KDC-serveren. Sårbarheden tillod ifølge erklæringen brugere at "løfte" deres privilegier til domæneniveau.

Se også

  • Single sign-on teknologi
  • identitetshåndtering
  • SPNEGO
  • S/Nøgle
  • SRP (Secure Remote Password Protocol)
  • GSS-API (Generic Security Services Application Program Interface)
  • Host Identity Protocol (HIP)

Noter

  1. ↑ Teknisk plan Arkiveret 1. januar 2016 på Athena Project Wayback Machine .
  2. ↑ Historien om navnet E-Bones  (utilgængeligt link)
  3. ↑ Meddelelse om Kerberos Version 4 End of Life . Hentet 11. november 2011. Arkiveret fra originalen 3. november 2011.

Litteratur

  • Schneier B. Kapitel 3. Grundlæggende protokoller. Kerberos Protocol // Anvendt kryptografi. Protokoller, algoritmer, kildekode i C-sprog = Applied Cryptography. Protokoller, algoritmer og kildekode i C. - M. : Triumf, 2002. - S. 81. - 816 s. - 3000 eksemplarer.  - ISBN 5-89392-055-4 .
  • Schneier B. Kapitel 24. Eksempler på praktiske implementeringer. KERBEROS-protokol // Anvendt kryptografi. Protokoller, algoritmer, kildekode i C-sprog = Applied Cryptography. Protokoller, algoritmer og kildekode i C. - M. : Triumf, 2002. - S. 627-633. — 816 s. - 3000 eksemplarer.  - ISBN 5-89392-055-4 .
  • Jason Garman . 1-3 // Kerberos: The Definitive Guide  (neopr.) . - 2003. - ISBN 0-596-00403-6 .
  • Schneier B. Kapitel 24.5 Kerberos Bruce Schneier // Anvendt kryptografi. Protokoller, algoritmer, kildekode i C-sprog = Applied Cryptography. Protocols, Algoritms and Source Code in C. - M. : Triumph, 2002. - 816 s. - 3000 eksemplarer.  - ISBN 5-89392-055-4 .

Links

 Autentificering og nøgleudvekslingsprotokoller
Med symmetriske algoritmer
Med symmetriske og
asymmetriske algoritmer
Protokoller og tjenester, der bruges på internettet