Forklar som jeg er 5 år gammel: Kerberos – hva er Kerberos, og hvorfor bør jeg bry meg?
Mens dette emnet sannsynligvis ikke kan forklares til en 5 år gammel og bli forstått, dette er mitt forsøk på å defragmentere dokumentasjon med noen visuelle hjelpemidler og fordøyelig språk.,
I et nøtteskall
i Utgangspunktet, Kerberos kommer ned til bare dette:
- en protokoll for godkjenning
- bruker billetter til å godkjenne
- unngår å lagre passord lokalt eller sende dem over internett
- innebærer en tiltrodd 3-part
- bygget på symmetrisk-kryptografi
Du har en billett – ditt bevis på din identitet er kryptert med en hemmelig nøkkel for den aktuelle tjenesten etterspør – på din lokale maskin (etablering av en billett som er beskrevet nedenfor), så lenge den er gyldig, kan du få tilgang til den valgte tjenesten som er innenfor en Kerberos-riket.,
dette er Vanligvis brukt innen corporate/interne miljøer. Kanskje du ønsker å få tilgang til dine interne lønn stedet for å gjennomgå hva som liten bonus sjefen din har gitt deg. Snarere enn å angi ditt brukernavn/passord legitimasjon, din billett (bufret på ditt system) brukes til å godkjenne slik at for single sign-on.
Din billett er uthvilt når du logger deg på datamaskinen, eller når du kinit USER i din terminal.
For de trivia-elskende folk, Kerberos’ navnet kommer fra gresk mytologi, tre-ledet vakt hund av Hades., Det er ganske passende, siden det tar en tredjepart (en Key Distribution Center) for å verifisere mellom en klient og en tjeneste eller vertsmaskinen.
Kerberos Riket
Administratorer skape verdener – Kerberos verdener – som vil omfatte alt som er tilgjengelig. Gitt, du kan ikke få tilgang til visse tjenester eller være vert for maskiner som er definert i policy management – utviklere bør ikke tilgang til noe finans-relaterte, ting som det. Men i en verden definerer hva Kerberos klarer i forhold til hvem som får tilgang til hva.,
Din maskin, Klienten, bor innenfor dette området, samt tjenesten eller verten som du vil be og Key Distribution Center, KDC (nei, ikke KGB, selv om jeg ikke alltid tror på det også). I følgende eksempel, jeg skille ut godkjenningsserveren og Billetten Tildeling av Server, men begge er innenfor KDC.
for Å holde det i bakhodet
Du kan gjerne komme tilbake hit når du har lest gjennom den mørke detaljer på hvordan de virker eksemplet.,
Når du ber om tilgang til en tjeneste eller vert, tre vekselsvirkningene foregår mellom deg og:
- godkjenningsserveren
- Billetten Gir Server
- Tjenesten eller vert maskin som du ønsker tilgang til.
Andre viktige punkter:
- Med samhandling, vil du motta to meldinger. Hver melding er en som du kan dekryptere, og en som du ikke kan.
- tjenesten eller maskin du ber om tilgang til aldri kommuniserer direkte med KDC.,
- KDC lagrer alle de hemmelige nøklene for brukeren maskiner og tjenester i sin database.
- Hemmelige nøkler er passord pluss et salt som er hashet – hash algoritmen er valgt ved implementering av Kerberos-oppsett. For tjenester eller vert maskiner, det er ingen passord (som ville skrive det). En nøkkel er faktisk generert av en admin under det første oppsettet og lært utenat på service/vertsmaskinen.
- Igjen, disse hemmelige nøkler er alle lagret i KDC database; husker Kerberos’ avhengighet av symmetrisk nøkkel kryptografi.,
- KDC i seg selv er kryptert med hovednøkkel til å legge et lag av vanskeligheten i å stjele nøklene fra databasen.
- Det er Kerberos-konfigurasjoner og implementeringer som bruker offentlig nøkkel kryptografi i stedet for symmetrisk nøkkel kryptering.
En side: rekkefølgen av meldinger og deres innhold som er diskutert her ikke reflekterer den rekkefølgen de sendes over TCP eller UDP.
eksempelet nedenfor beskriver hva som skjer når du ber om noe fra en intern HTTP-Tjeneste – som informasjon om lønn innenfor bedriftens intranett.,
Du og Godkjenning Server
Du vil ha tilgang til en HTTP-Tjenesten, men først må du introdusere deg selv til godkjenningsserveren. Logge inn på din datamaskin, eller kinit USERNAME, initierer at innføring via en ren tekst forespørsel for en Billett Gir Billett (TGT)., Ren tekst meldingen inneholder:
- navn/ID
- navn/ID av den forespurte tjenesten (i dette tilfellet, service er Billetten Gir Server),
- nettverks-adresse (kan være en liste over IP-adresser for flere maskiner, eller kan være null hvis du ønsker å bruke på hvilken som helst maskin), og
- bedt om levetid for gyldigheten av TGT,
og er sendt til godkjenningsserveren.
godkjenningsserveren vil sjekke om du er i KDC database. Denne avmerkingsboksen er bare å se hvis du finnes, ingen legitimasjonsbeskrivelsene er kontrollert.,
Hvis det er noen feil (f.eks. brukernavn er ikke funnet), det vil tilfeldig generere en nøkkel kalles en session-tasten for bruk mellom deg og Billett Tildeling Server (TGS).
godkjenningsserveren vil deretter sende to meldinger tilbake til deg., En melding er TGT som inneholder:
- navn/ID
- TGS navn/ID
- tidsstempel,
- nettverks-adresse (kan være en liste over IP-adresser for flere maskiner, eller kan være null hvis du ønsker å bruke på hvilken som helst maskin)
- levetid TGT (kan være hva du i utgangspunktet bedt om, lavere hvis du eller TGS hemmelige nøkler er i ferd med å utløpe, eller annen grense som ble implementert i løpet av Kerberos-oppsett), og
- TGS sesjonsnøkkelen,
og er kryptert med TGS Hemmelig Nøkkel ., Den andre meldingen inneholder:
- TGS navn/ID
- tidsstempel,
- levetid (samme som ovenfor), og
- TGS Økt Tasten
og er kryptert med Klienten din Hemmelige Nøkkel. Vær oppmerksom på at TGS Session Key er delt nøkkel mellom deg og TGS.
Din Klient Hemmelig Nøkkel bestemmes ved å be deg om passordet ditt, legge til et salt (som består av ) og hashing hele greia. Nå kan du bruke det for å dekryptere den andre meldingen for å få TGS sesjonsnøkkelen., Hvis passordet er feil, så vil du ikke være i stand til å dekryptere meldingen. Vær oppmerksom på at dette er det trinnet der passordet du taster inn er implisitt validert.
Du kan imidlertid ikke rett til å dekryptere TGT siden du ikke vet TGS Hemmelig Nøkkel. Den krypterte TGT er lagret i ditt credential cache.
Du og Billetten Gir Server
På dette punktet, du har TGT at du ikke kan lese fordi du ikke har TGS Hemmelige Nøkkel til å dekryptere det. Du har imidlertid TGS sesjonsnøkkelen.,
Det er nå din tur til å sende to meldinger. Du først forberede Autentisering, kryptert med TGS sesjonsnøkkelen, som inneholder:
- navn/ID, og
- tidsstempel.
Du vil sende en kryptert melding som inneholder:
- den forespurte HTTP Service navn/ID du ønsker tilgang til, og
- levetid Billett for HTTP-Tjenesten,
sammen med den krypterte Autentisering og TGT til Billett Tildeling av Server.
Billetten Tildeling av Server vil først sjekke KDC databasen for å se om HTTP-Tjenesten finnes.,
Hvis så, TGS dekrypterer TGT med sin Hemmelige Nøkkel . Siden det nå-ukryptert TGT inneholder TGS sesjonsnøkkelen, TGS kan dekryptere Autentisering du har sendt.,grunn:
- sammenligne din klient-ID fra Autentisering som TGT
- sammenlign tidsstempelet fra Autentisering som TGT (typisk Kerberos-system toleranse av forskjellen ligger 2 minutter, men kan konfigureres på annen måte)
- sjekk for å se om TGT er utløpt (lifetime-element),
- kontroller at Autentisering ikke allerede er i TGS ‘ s cache (for å unngå angrep), og
- hvis nettverket adresse i den opprinnelige forespørselen ikke er null, sammenligner kilde-IP-adresse til nettverket adresse (eller innen den angitte listen) i TGT.,
Billetten Tildeling av Server og deretter genererer tilfeldige HTTP-Tjenesten sesjonsnøkkelen, og forbereder HTTP-Tjenesten billetten for deg som inneholder:
- navn/ID
- HTTP Service navn/ID
- nettverks-adresse (kan være en liste over IP-adresser for flere maskiner, eller kan være null hvis du ønsker å bruke på hvilken som helst maskin),
- tidsstempel,
- levetid på gyldigheten av billetten, og
- HTTP Service sesjonsnøkkelen,
og krypterer den med HTTP-Tjenesten Hemmelig Nøkkel.
Så TGS sender deg to meldinger., Den ene er kryptert HTTP Service-Billett, den andre inneholder:
- HTTP Service navn/ID
- tidsstempel,
- levetid på gyldigheten av billetten, og
- HTTP Service sesjonsnøkkelen,
som er kryptert med TGS sesjonsnøkkelen.
Din maskin dekrypterer den siste meldingen med TGS sesjonsnøkkelen at det bufret tidligere å få tak i HTTP-Tjenesten sesjonsnøkkelen.
Din maskin kan imidlertid ikke rett til å dekryptere HTTP Service Billett, siden det er kryptert med HTTP-Tjenesten Hemmelig Nøkkel.,
Du og HTTP-Tjenesten
for Å nå få tilgang til HTTP-Tjenesten, maskinen forbereder en annen Autentisering melding som inneholder:
- navn/ID
- tidsstempel,
og er kryptert med HTTP-Tjenesten sesjonsnøkkelen. Maskinen sender deretter Autentisering og fortsatt er kryptert HTTP Service Billett mottatt fra TGS.
HTTP-Tjenesten deretter dekrypterer Billett med sin Hemmelige Nøkkel til å få tak i HTTP-Tjenesten sesjonsnøkkelen., Det bruker denne Økten Nøkkelen til å dekryptere Autentisering meldingen du sendte.,es din klient-ID fra google Autentisering-som for Billetten,
HTTP-Tjenesten sender deretter en Autentisering melding som inneholder ID-og tidsstempel for å bekrefte sin identitet til deg og din er kryptert med HTTP-Tjenesten sesjonsnøkkelen.
maskinen leser Autentisering meldingen ved å dekryptere med den bufrede HTTP Service sesjonsnøkkelen, og vet at det har å motta en melding med HTTP-Tjeneste-ID og tidsstempel.
Og nå har du blitt godkjent til å bruke HTTP-Tjeneste., Fremtidige forespørsler bruke bufret HTTP Service Billett, så lenge det ikke har utløpt, som definert i livet attributtet.
Mens jeg vil skrive om dette senere, HTTP-Tjenesten i seg selv må være i stand til å støtte Kerberos. I tillegg må du også ha en nettleser som støtter SPNEGO/Forhandle.,
Kanskje re-lese poeng tidligere skissert, sjekk ut dette eller dette gjeldende implementering, spesielt den som jeg er betalt for å jobbe som kommuniserer med denne populære gjennomføring, eller gjennomgå en tutorial, ressurs guide, go-til-video som ble sendt til meg når jeg begynte å lære om Kerberos, eller RFC seg selv.
over bilder som ble gjengitt med Keynote med ikoner brukt fra skriften awesome og glyphicons, og er tilgjengelig på slideshare.