Kerberos (protokol)

Historie og udvikling

MIT udviklede Kerberos for at beskytte netværkstjenester, der blev leveret af Project Athena. Protokollen blev opkaldt efter den græske mytologiske figur Kerberos (eller Cerberus), der i den græske mytologi er kendt som Hades' uhyrlige trehovedede vagthund. Der findes flere versioner af protokollen; version 1-3 anvendes kun internt på MIT.

Steve Miller og Clifford Neuman, de primære designere af Kerberos version 4 (som brugte DES-krypteringsalgoritmen med 56-bit nøgler), offentliggjorde denne version i 1989, selv om de primært havde målrettet den til Project Athena.

Version 5, der er designet af John Kohl og Clifford Neuman, blev offentliggjort som RFC 1510 i 1993 (forældet af RFC 4120 i 2005) med henblik på at overvinde begrænsningerne og sikkerhedsproblemerne i version 4. MIT stiller en implementering af Kerberos version 5 frit til rådighed under en softwarelicens svarende til den, der anvendes af BSD-licensen.

Flere virksomheder har brugt Kerberos version 5 i kommerciel software, herunder:

·         Microsofts Windows 2000 og nyere versioner anvender Kerberos som standardgodkendelsesmetode.
Nogle af Microsofts tilføjelser til Kerberos-protokollerne er dokumenteret i RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols".
RFC 4757 dokumenterer Microsofts brug af RC4-cifringen. Microsoft anvender Kerberos-protokollen, men ikke MIT-softwaren[1].

·         Apples Mac OS X bruger også Kerberos i både klient- og serverversioner.

·         Red Hat Linux version 4 og senere bruger Kerberos i både klient- og serverversioner.

I 2005 introducerede IETF Kerberos-arbejdsgruppen en ny opdateret specifikation for Kerberos Version 5 [2].Opdateringerne omfatter:

·         "Specifikationer for kryptering og kontrolsummer" (RFC 3961),

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

·         En ny udgave af Kerberos version 5-specifikationen "The Kerberos Network Authentication Service (V5)" (RFC 4120). Denne version forælder RFC 1510 og præciserer aspekter af protokollen og den tilsigtede anvendelse i en mere detaljeret og klar forklaring,

·         En ny udgave af GSS-API-specifikationen "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism" (Kerberos version 5 generisk sikkerhedstjenesteprogramgrænseflade (GSS-API): Version 2." (RFC 4121).

I 2007 dannede MIT Kerberos Consortium for at fortsætte udviklingen.

Protokol

Kerberos anvender Needham-Schroeder-protokollen som sit grundlag. Den anvender en pålidelig tredjepartsautentifikation, der er kendt som "key distribution center (KDC)", som består af to logisk adskilte dele: en autentifikationsserver (AS) og en billetudstedende server (TGS). Kerberos fungerer på grundlag af "billetter" (kaldet Kerberos-billetter), som tjener til at bevise brugernes identitet.

Kerberos-database: Hver enhed på netværket - uanset om det er en klient eller en server - deler en hemmelig nøgle, som kun er kendt af den selv og af KDC. Kendskab til denne nøgle tjener til at bevise den enkelte enheds identitet. Ved kommunikation mellem to enheder genererer KDC en sessionsnøgle, som de kan bruge til at sikre deres kommunikation.

Udtrykket "Kerberos-server" henviser generelt til KDC'en. Af hensyn til pålideligheden er det muligt at have backup-KDC'er. Disse kaldes "Kerberos-slaveservere". Alle slaver synkroniserer deres databaser fra master Kerberos-serveren.

Udtrykket "Kerberized applikationsserver" henviser generelt til Kerberized-programmer, som klienter kommunikerer med ved hjælp af Kerberos-billetter til autentificering. Kerberos-telnet-serveren er f.eks. et eksempel på en Kerberiseret applikationsserver . Mens udtrykket "Kerberized applikationer" bruges til at henvise til klientsiden af Kerberized applikationsserveren, er Kerberos telnet-klienten f.eks. et eksempel på en Kerberized applikationsserver.

Protokollens sikkerhed afhænger i høj grad af:

1. Deltagere, der opretholder løst synkroniseret tid.
2. En kortvarig erklæring om autenticitet: Kerberos-billetter.

Forenklet beskrivelse af protokollen

Følgende forkortelser vil blive anvendt:

·         AS = autentificeringsserver

·         TGS = server til udstedelse af billetter

·         SS eller Server = Service Server (Serverbruger, der anmoder om sin tjeneste, f.eks. en printserver, en filserver osv...)

·         TGT = Ticket Granting Ticket (Kerberos-billet til TGS. Udarbejdes af AS og bruges derefter til at tale med TGS).

Kort fortalt autentificerer klienten sig over for AS ved hjælp af en langsigtet delt hemmelighed og modtager en billet fra AS. Senere kan klienten bruge denne billet til at få yderligere billetter til SS ved hjælp af den samme delte hemmelighed. Disse billetter kan bruges til at bevise autentificering over for SS.

Protokollen i detaljer

Brugerklientbaserede logon-trin:

1. En bruger indtaster et brugernavn og en adgangskode på klientmaskinen.
2. Klienten udfører en envejsfunktion (for det meste en Hash-funktion) på det indtastede password, og dette bliver klientens/brugerens hemmelige nøgle.

Trin for klientgodkendelse:

1. Klienten sender en klartekstbesked til AS'et og anmoder om tjenester på brugerens vegne.
   Eksempel på en meddelelse: "Bruger XYZ vil gerne anmode om tjenester".
   Bemærk: Hverken den hemmelige nøgle eller adgangskoden sendes til AS.
2. AS kontrollerer, om klienten findes i dets database. Hvis den er det, sender AS'et følgende to meddelelser tilbage til klienten:
• Meddelelse A: Klient/TGS-sessionsnøgle krypteret ved hjælp af klientens/brugerens hemmelige nøgle.
• Meddelelse B: TGT (som indeholder klient-ID, klientnetværksadresse, billetgyldighedsperiode og klient/TGS-sessionsnøglen) krypteret ved hjælp af TGS's hemmelige nøgle.
3. Når klienten modtager meddelelserne A og B, dekrypterer den meddelelse A for at få klient/TGS-sessionsnøglen. Denne sessionsnøgle bruges til yderligere kommunikation med TGS. På dette tidspunkt har klienten tilstrækkelige oplysninger til at autentificere sig selv over for TGS.
   Bemærk: Klienten kan ikke dekryptere meddelelse B, da den er krypteret ved hjælp af TGS's hemmelige nøgle.

Godkendelsestrin i kundeservice:

1. Når klienten anmoder om tjenester, sender den følgende to meddelelser til TGS'et:
• Meddelelse C: Består af TGT'en fra meddelelse B og ID'et for den anmodede tjeneste.
• Meddelelse D: Autenticator (som består af klient-ID og tidsstempel), krypteret ved hjælp af klient/TGS-sessionsnøglen.
2. Efter at have modtaget meddelelserne C og D henter TGS meddelelsen B ud af meddelelsen C. Den dekrypterer meddelelsen B ved hjælp af TGS's hemmelige nøgle. Dette giver den klient/TGS-sessionsnøglen. Ved hjælp af denne nøgle dekrypterer TGS meddelelsen D (Authenticator) og sender følgende to meddelelser til klienten:
• Meddelelse E: Klient-til-server-billet (som indeholder klient-ID, klientnetværksadresse, gyldighedsperiode og klient/server-sessionsnøgle) krypteret ved hjælp af SS's hemmelige nøgle.
• Meddelelse F: Klient/Server-sessionsnøgle krypteret med klient/TGS-sessionsnøglen.

Trin for anmodning om kundeservice:

1. Når klienten modtager meddelelserne E og F fra TGS, har den tilstrækkelige oplysninger til at autentificere sig over for SS. Klienten opretter forbindelse til SS og sender følgende to meddelelser:
• Meddelelse E: fra det foregående trin (klient-til-server-billetten, krypteret ved hjælp af SS's hemmelige nøgle).
• Meddelelse G: en ny Authenticator, som indeholder klient-ID, tidsstempel og er krypteret ved hjælp af klient/server-sessionsnøglen.
2. SS dekrypterer billetten ved hjælp af sin egen hemmelige nøgle for at hente klient/server-sessionsnøglen. Ved hjælp af sessionsnøglen dekrypterer SS Authenticator og sender følgende meddelelse til klienten for at bekræfte sin sande identitet og sin vilje til at betjene klienten:
• Meddelelse H: det tidsstempel, der findes i klientens Authenticator plus 1, krypteret ved hjælp af klient/server-sessionsnøglen.
3. Klienten dekrypterer bekræftelsen ved hjælp af klient/server-sessionsnøglen og kontrollerer, om tidsstemplet er korrekt opdateret. Hvis det er tilfældet, kan klienten stole på serveren og begynde at sende tjenesteanmodninger til serveren.
4. Serveren leverer de ønskede tjenester til klienten.

Ulemper

• Enkeltstående fejl: Det kræver kontinuerlig tilgængelighed af en central server. Når Kerberos-serveren er nede, kan ingen logge ind. Dette kan løses ved at anvende flere Kerberos-servere og nødgodkendelsesmekanismer.
• Kerberos kræver, at urene på alle involverede værter er synkroniserede. Billetterne har en tidstilgængelighedsperiode, og hvis værtens ur ikke er synkroniseret med Kerberos-serverens ur, vil godkendelsen mislykkes. Standardkonfigurationen kræver, at der ikke er mere end 10 minutters mellemrum mellem urene. I praksis bruges Network Time Protocol (NTP) normalt til at holde alle værter synkroniseret.
• Administrationsprotokollen er ikke standardiseret og varierer fra serverimplementation til serverimplementation. Ændringer af adgangskoder er beskrevet i RFC 3244.
• Da de hemmelige nøgler for alle brugere er gemt på den centrale server, vil en kompromittering af denne server kompromittere alle brugernes hemmelige nøgler.
• En kompromitteret klient vil kompromittere brugerens adgangskode.

Relaterede sider

• Identitetsstyring
• Sikker fjernadgangskodeprotokol (SRP)
• Programgrænseflade for generiske sikkerhedstjenester (GSS-API)