Forklare, som jeg er 5 år gammel: Kerberos – hvad er Kerberos, og hvorfor skulle jeg pleje?selvom dette emne sandsynligvis ikke kan forklares for en 5-årig og forstås, er dette mit forsøg på at defragmentere dokumentation med nogle visuelle hjælpemidler og fordøjeligt sprog.,

I en nøddeskal

Dybest set, Kerberos kommer ned til blot dette:

  • en protokol til godkendelse
  • bruger billetter til godkendelse
  • undgår lagring af passwords lokalt eller sende dem over internettet
  • involverer en betroet 3.-part
  • bygget på symmetric-key kryptografi

Du har en billet – dit bevis af identitet, der er krypteret med en hemmelig nøgle, der for den pågældende tjeneste – på din lokale maskine (oprettelse af en billet er beskrevet nedenfor); så længe det er gyldigt, kan du få adgang til den ønskede tjeneste, der er inden for en adskilt opgave.,

typisk bruges dette inden for virksomheds / interne miljøer. Måske vil du få adgang til dit interne lønningsliste for at gennemgå, hvilken lille bonus din chef har givet dig. I stedet for at indtaste dine bruger-/adgangskodeoplysninger igen, bruges din billet (cachelagret på dit system) til at godkende, hvilket giver mulighed for enkeltlogon.

din billet opdateres, når du logger på din computer, eller når du kinit USER i din terminal.

for de trivia-elskende folk kommer Kerberos’ navn fra græsk mytologi, den trehovedede vagthund af Hades., Det er temmelig passende, da det tager en tredjepart (et Nøgledistributionscenter) at godkende mellem en klient og en service-eller værtsmaskine.

Wikipedia

Kerberos Realm

Admins skaber realms – Kerberos realms – der vil omfatte alle, der er tilgængelige for adgang. Indrømmet, du kan ikke have adgang til visse tjenester eller vært maskiner, der er defineret inden for politik management – udviklere bør ikke få adgang til noget finans relaterede, ting som det. Men et rige definerer, hvad Kerberos administrerer med hensyn til, hvem der kan få adgang til hvad.,

din maskine, klienten, bor inden for dette område, såvel som den service eller vært, du vil anmode om, og Key Distribution Center, KDC (Nej, ikke KGB, selvom jeg altid tænker på det også). I det følgende eksempel adskiller jeg godkendelsesserveren og Billettildelingsserveren, men begge er inden for KDC.

for at holde bag i dit sind

kan du komme tilbage her, når du har læst de gritty detaljer om, hvordan eksemplet fungerer.,

Når du anmoder om adgang til en service eller vært, tre interaktioner, der finder sted mellem dig og:

  • Authentication Server
  • Billetten Ydelse-Server
  • Tjenesten eller host maskinen, som du ønsker adgang til.

andre vigtige punkter:

  • ved hver interaktion modtager du to meddelelser. Hver meddelelse er en, som du kan dekryptere, og en, som du ikke kan.den service eller maskine, du anmoder om adgang til, kommunikerer aldrig direkte med KDC.,
  • KDC gemmer alle de hemmelige nøgler til brugermaskiner og-tjenester i sin database.
  • hemmelige nøgler er adgangskoder plus et salt, der er hashet – hash-algoritmen vælges under implementeringen af Kerberos-opsætningen. For tjenester eller værtsmaskiner er der ingen adgangskoder (hvem ville indtaste det). En nøgle genereres faktisk af en administrator under den første opsætning og gemmes på service/host-maskinen.
  • igen gemmes disse hemmelige nøgler alle i KDC-databasen; husk Kerberos ‘ afhængighed af symmetrisk nøglekryptografi.,
  • KDC selv er krypteret med en hovednøgle for at tilføje et lag af vanskeligheder fra at stjæle nøgler fra databasen.
  • Der er Kerberos-konfigurationer og implementeringer, der bruger kryptografi med offentlig nøgle i stedet for symmetrisk nøglekryptering.

en side: rækkefølgen af meddelelserne og deres indhold, der diskuteres her, afspejler ikke den rækkefølge, de sendes over TCP eller UDP.

eksemplet nedenfor beskriver, hvad der sker, når du anmoder om noget fra en intern HTTP – tjeneste-lignende oplysninger om lønningslisten i din virksomheds intranet.,

dig og godkendelsesserveren

du vil have adgang til en HTTP-tjeneste, men først skal du introducere dig selv til godkendelsesserveren. Log ind på din computer, eller kinit USERNAME, initierer denne introduktion via en klartekst anmodning om en billet tildeling billet (TGT)., Alm besked indeholder:

  • dit navn/ID
  • fornavn/ID af den ønskede service (i dette tilfælde er Billetten Ydelse Server),
  • dit netværk-adresse (som kan være en liste af IP-adresser for flere maskiner, eller kan være null, hvis du ønsker at bruge på enhver maskine), og
  • anmodede levetid for gyldigheden af de TGT

og er sendt til godkendelsesserveren.

Autentificeringsserveren kontrollerer, om du er i KDC-databasen. Denne kontrol er kun for at se, om du eksisterer; ingen legitimationsoplysninger er markeret.,

Hvis der ikke er nogen fejl (f.eks. Brugeren ikke findes), vil det tilfældigt generere en nøgle kaldet en sessionnøgle til brug mellem dig og Ticket Grant Server (TGS).

Autentificeringsserveren sender derefter to meddelelser tilbage til dig., En besked er TGT-fil, der indeholder:

  • dit navn/ID,
  • TGS navn/ID,
  • timestamp,
  • dit netværk-adresse (som kan være en liste af IP-adresser for flere maskiner, eller kan være null, hvis du ønsker at bruge på enhver maskine)
  • levetid TGT (kunne være hvad du oprindeligt har anmodet om, lavere, hvis du eller TG ‘ s hemmelige nøgler er ved at udløbe, eller anden grænse, der blev gennemført i løbet af Kerberos-installation), og
  • TGS-Session-Nøgle,

og er krypteret med TGS Hemmelige Nøgle ., Den anden meddelelse indeholder:

  • TGS navn/ID,
  • timestamp,
  • levetid (samme som ovenfor), og
  • TGS-Session-Nøgle

og er krypteret med din Klient Hemmelig Nøgle. Bemærk, at TGS-Sessionsnøglen er den delte nøgle mellem dig og TGS.

din klient hemmelige nøgle bestemmes ved at bede dig om din adgangskode, tilføje et salt (bestående af ) og hashing det hele. Nu kan du bruge den til dekryptering af den anden meddelelse for at få TGS-Sessionsnøglen., Hvis adgangskoden er forkert, kan du ikke dekryptere meddelelsen. Bemærk, at dette er det trin, hvor den adgangskode, du indtaster, implicit er valideret.

Du kan dog ikke dekryptere TGT, da du ikke kender TGS Hemmelige Nøgle. Den krypterede TGT gemmes i din legitimations cache.

du og den Billettildelende Server

På dette tidspunkt har du TGT, som du ikke kan læse, fordi du ikke har TGS-hemmelig nøgle til at dekryptere den. Du har dog TGS-Sessionsnøglen.,

det er nu din tur til at sende to meddelelser. Du forbereder først autentifikatoren, krypteret med TGS-Sessionsnøglen, der indeholder:

  • dit navn/ID og
  • tidsstempel.

Du sender en krypteret meddelelse, der indeholder:

  • den anmodede HTTP-Tjeneste navn/ID, du vil have adgang til, og
  • levetid Billet til HTTP-Tjenesten,

sammen med den krypterede Autentificering og TGT til Billet Ydelse Server.

den server, der tildeler billetter, tjekker først KDC-databasen for at se, om HTTP-tjenesten findes.,

i så fald dekrypterer TGS TGT med sin hemmelige nøgle . Da den nu ikke-krypterede TGT indeholder TGS-Sessionsnøglen, kan TGS dekryptere den autentificering, du har sendt.,på grund af:

  • undersøg dit kunde-ID fra Autentificering til TGT
  • sammenlign tidsstemplet fra Autentificering til TGT (typisk Kerberos-system tolerance forskel er 2 minutter, men kan konfigureres på anden måde)
  • tjek for at se, om TGT er udløbet (den levetid element),
  • tjek, at den Autentificering ikke allerede er i TG ‘ s cache (for at undgå replay attacks), og
  • hvis adressen i den oprindelige anmodning ikke er null, sammenligner kilde-IP-adresse til dit netværk-adresse (eller inden for den ønskede liste) inden for de TGT.,

Billetten Ydelse Server, så genererer tilfældigt HTTP-Tjenesten Session Nøgle, og forbereder HTTP-Tjeneste billet til jer, der indeholder:

  • dit navn/ID,
  • HTTP Service name/ID,
  • dit netværk-adresse (som kan være en liste af IP-adresser for flere maskiner, eller kan være null, hvis du ønsker at bruge på alle maskiner),
  • timestamp,
  • levetid af gyldigheden af billetten, og
  • HTTP Service Session Nøgle,

og krypterer den med HTTP-Tjenesten Hemmelige Nøgle.

derefter sender TGS dig to meddelelser., Den ene er den krypterede http-Servicebillet; den anden indeholder:

  • HTTP-servicenavn/ID,
  • tidsstempel,
  • levetid for billettens gyldighed og
  • http-Servicesessionsnøgle,

, Der er krypteret med TGS-Sessionsnøglen.

din maskine dekrypterer sidstnævnte meddelelse med TGS-Sessionsnøglen, som den cachede tidligere for at få http-Servicesessionsnøglen.

din maskine kan dog ikke dekryptere http-Servicebilletten, da den er krypteret med HTTP-tjenestens hemmelige nøgle.,

Dig og HTTP-Service

nu få adgang til HTTP-Tjenesten, vil din maskine forbereder en anden Autentificering besked, der indeholder:

  • dit navn/ID,
  • timestamp,

og er krypteret med HTTP-Tjenesten Session Nøgle. Din maskine sender derefter autentifikatoren og den stadig krypterede http-Servicebillet modtaget fra TGS.

HTTP-tjenesten dekrypterer derefter billetten med sin hemmelige nøgle for at få http-Servicesessionsnøglen., Den bruger derefter denne sessionsnøgle til at dekryptere Autentificeringsmeddelelsen, du har sendt.,es dit kunde-ID fra Autentificering til Billetten,

  • sammenligner timestamp fra Autentificering, at Billetten (typisk Kerberos-system tolerance forskel er 2 minutter, men kan konfigureres på anden måde),
  • kontroller for at se, om Billetten er udløbet (den levetid element),
  • kontroller, at det Autentificering ikke allerede er i HTTP-servers cache (for at undgå replay attacks), og
  • hvis adressen i den oprindelige anmodning ikke er null, sammenligner kilde-IP-adresse til dit netværk-adresse (eller inden for den ønskede liste) inden for Billetten.,
  • HTTP-tjenesten sender derefter en Autentificeringsmeddelelse, der indeholder dens ID og tidsstempel for at bekræfte dens identitet til dig og er krypteret med HTTP-Servicesessionsnøglen.

    din maskine læser Autentificeringsmeddelelsen ved at dekryptere med den cachelagrede http-Servicesessionsnøgle og ved, at den skal modtage en besked med HTTP-tjenestens ID og tidsstempel.

    og nu er du blevet godkendt til at bruge HTTP-tjenesten., Fremtidige anmodninger bruger den cachelagrede http-Servicebillet, så længe den ikke er udløbet som defineret inden for levetidsattributten.

    mens jeg vil skrive om dette senere, skal HTTP-tjenesten selv kunne understøtte Kerberos. Samt, du skal også have en bro .ser, der understøtter SPNEGO/forhandle.,

    Måske re-læs de punkter, som tidligere skitseret, tjek det, eller det nuværende implementering, især den ene, som jeg bliver betalt for at arbejde, der kommunikerer med denne populære gennemførelse, eller gennemgå en tutorial, ressource guide, gå-til-video, der er sendt til mig, da jeg begyndte at lære om Kerberos, eller RFC selv.ovenstående billeder blev gengivet med Keynote med ikoner brugt fra font a .esome og glyphicons, og er tilgængelige på slideshare.

    Skriv et svar

    Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *