Kerberos (tietotekniikka)

Historia ja kehitys

MIT kehitti Kerberosin suojaamaan Project Athenan tarjoamia verkkopalveluja. Protokolla nimettiin kreikkalaisen mytologian hahmon Kerberos (tai Cerberos) mukaan, joka tunnetaan kreikkalaisessa mytologiassa Haadeksen hirviömäisenä kolmipäisenä vartijakoirana. Protokollasta on olemassa useita versioita; versiot 1-3 ovat käytössä vain MIT:n sisäisesti.

Steve Miller ja Clifford Neuman, Kerberos-version 4 (joka käytti DES-salausalgoritmia 56-bittisillä avaimilla) pääsuunnittelijat, julkaisivat kyseisen version vuonna 1989, vaikka he olivatkin suunnitelleet sen ensisijaisesti Athena-projektia varten.

John Kohlin ja Clifford Neumanin suunnittelema versio 5 ilmestyi RFC 1510:nä vuonna 1993 (RFC 4120 poisti sen käytöstä vuonna 2005), ja sen tarkoituksena oli poistaa version 4 rajoitukset ja turvallisuusongelmat. MIT tarjoaa Kerberos Version 5:n toteutuksen vapaasti saataville BSD-lisenssin kaltaisella ohjelmistolisenssillä.

Useat yritykset käyttivät Kerberosin versiota 5 kaupallisissa ohjelmistoissa, mukaan lukien:

·         Microsoftin Windows 2000 ja uudemmat versiot käyttävät Kerberos-järjestelmää oletustodennusmenetelmänä.
Joitakin Microsoftin lisäyksiä Kerberos-protokollien sarjaan on dokumentoitu asiakirjassa RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols"
.
RFC 4757 dokumentoi Microsoftin RC4-salauksen
käytön.
Vaikka Microsoft käyttää Kerberos-protokollaa, se ei käytä MIT-ohjelmistoa[1].

·         Myös Applen Mac OS X käyttää Kerberosia sekä asiakas- että palvelinversiossaan.

·         Red Hat Linuxin versio 4 ja uudemmat versiot käyttävät Kerberosia sekä asiakas- että palvelinversioissa.

Vuonna 2005 IETF:n Kerberos-työryhmä esitteli uudet päivitetyt eritelmät Kerberosin versiolle 5 [2]. päivitykset sisältävät seuraavat:

·         "Encryption and Checksum Specifications" (RFC 3961),

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

·         Uusi painos Kerberos Version 5 -määrittelystä "The Kerberos Network Authentication Service (V5)" (RFC 4120). Tämä versio poistaa RFC 1510:n ja selventää protokollan ja käyttötarkoituksen näkökohtia yksityiskohtaisemmalla ja selkeämmällä selityksellä,

·         Uusi painos GSS-API-määrittelystä "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Versio 2." (RFC 4121).

Vuonna 2007 MIT perusti Kerberos-konsortion jatkamaan kehitystä.

Protokolla

Kerberos käyttää perustana Needham-Schroeder-protokollaa. Se käyttää luotettavaa kolmannen osapuolen todennusta, joka tunnetaan nimellä "key distribution center (KDC)" ja joka koostuu kahdesta loogisesti erillisestä osasta: todennuspalvelimesta (Authentication Server, AS) ja lipunmyyntipalvelimesta (Ticket Granting Server, TGS). Kerberos toimii "lippujen" (ns. Kerberos-lippujen) perusteella, joilla todistetaan käyttäjien henkilöllisyys.

Kerberos-tietokanta: Jokainen verkossa oleva yksikkö - olipa kyseessä asiakas tai palvelin - jakaa salaisen avaimen, jonka tuntee vain se itse ja KDC. Tämän avaimen tunteminen todistaa kunkin yksikön henkilöllisyyden. Kahden yksikön välistä viestintää varten KDC luo istuntoavaimen, jota yksiköt voivat käyttää viestinnän suojaamiseen.

Termi "Kerberos-palvelin" viittaa yleensä KDC:hen. Luotettavuussyistä on mahdollista käyttää varakeskuksia. Näitä kutsutaan "Kerberos-orjapalvelimiksi". Kaikki orjat synkronoivat tietokantansa Kerberos-pääpalvelimelta.

Termi "Kerberisoitu sovelluspalvelin" viittaa yleensä Kerberisoituihin ohjelmiin, joiden kanssa asiakkaat kommunikoivat käyttäen Kerberos-lippuja todennukseen. Esimerkiksi Kerberos-telnet-palvelin on esimerkki Kerberisoidusta sovelluspalvelimesta . Kun taas termiä "Kerberisoidut sovellukset" käytetään viittaamaan Kerberisoidun sovelluspalvelimen asiakaspuoleen , Esimerkiksi Kerberos telnet-asiakasohjelma on esimerkki Kerberisoidusta sovelluksesta.

Protokollan turvallisuus riippuu pitkälti seuraavista tekijöistä:

1. Osallistujat säilyttävät löyhästi synkronoidun ajan.
2. Lyhytikäinen aitouden osoitus: Kerberos-liput.

Protokollan yksinkertaistettu kuvaus

Käytetään seuraavia lyhenteitä:

·         AS = Todennuspalvelin

·         TGS = Ticket Granting Server

·         SS tai Server = Service Server (palvelimen käyttäjä, joka pyytää palvelua, kuten tulostuspalvelin, tiedostopalvelin jne...).

·         TGT = Ticket Granting Ticket (TGS:n Kerberos-lippu, jonka AS laatii ja jota käytetään keskusteluun TGS:n kanssa).

Lyhyesti sanottuna asiakas tunnistautuu liitännäisjärjestelmään käyttämällä pitkäaikaista jaettua salaisuutta ja saa liitännäisjärjestelmältä lipun. Myöhemmin asiakas voi käyttää tätä lippua saadakseen lisää lippuja SS:lle käyttäen samaa jaettua salaisuutta. Näitä lippuja voidaan käyttää todentamisen osoittamiseen SS:lle.

Protokolla yksityiskohtaisemmin

Käyttäjän asiakaspohjaiset kirjautumisvaiheet:

1. Käyttäjä syöttää käyttäjätunnuksen ja salasanan asiakaskoneella.
2. Asiakas suorittaa syötetylle salasanalle yksisuuntaisen toiminnon (useimmiten Hash-funktion), josta tulee asiakkaan/käyttäjän salainen avain.

Asiakkaan todennuksen vaiheet:

1. Asiakas lähettää liitännäisjärjestelmälle selväkielisen viestin, jossa pyydetään palveluja käyttäjän puolesta.
   Esimerkkiviesti: "Käyttäjä XYZ haluaa pyytää palveluja".
   Huomautus: Salaista avainta tai salasanaa ei lähetetä liitännäisjärjestelmälle.
2. Liitännäisjärjestelmä tarkistaa, onko asiakas sen tietokannassa. Jos on, liitännäisjärjestelmä lähettää asiakkaalle seuraavat kaksi viestiä:
• Viesti A: Asiakkaan/TGS-istunnon avain salattuna asiakkaan/käyttäjän salaisella avaimella.
• Viesti B: TGT (joka sisältää asiakastunnuksen, asiakkaan verkko-osoitteen, lipun voimassaoloajan ja asiakkaan ja TGS:n istuntoavaimen), joka on salattu TGS:n salaisella avaimella.
3. Kun asiakas vastaanottaa viestit A ja B, se purkaa viestin A saadakseen asiakkaan ja TGS:n istuntoavaimen. Tätä istuntoavainta käytetään jatkossa viestintään TGS:n kanssa. Tässä vaiheessa asiakkaalla on riittävästi tietoa todentaakseen itsensä TGS:lle.
   Huomautus: Asiakas ei voi purkaa viestiä B, koska se on salattu TGS:n salaisella avaimella.

Asiakaspalvelun valtuutuksen vaiheet:

1. Kun asiakas pyytää palveluja, hän lähettää TGS:lle seuraavat kaksi viestiä:
• Sanoma C: Koostuu sanoman B TGT:stä ja pyydetyn palvelun tunnuksesta.
• Viesti D: Todentaja (joka koostuu asiakkaan tunnisteesta ja aikaleimasta), joka on salattu asiakkaan ja TGS:n istuntoavaimella.
2. Saatuaan viestit C ja D TGS hakee viestin B viestistä C. Se purkaa viestin B salauksen TGS:n salaisella avaimella. Näin se saa asiakkaan ja TGS:n istuntoavaimen. Tämän avaimen avulla TGS purkaa viestin D (Authenticator) salauksen ja lähettää seuraavat kaksi viestiä asiakkaalle:
• Viesti E: Asiakkaan ja palvelimen välinen lippu (joka sisältää asiakkaan tunnuksen, asiakkaan verkko-osoitteen, voimassaoloajan ja asiakkaan ja palvelimen istuntoavaimen), joka on salattu SS-salaisella avaimella.
• Viesti F: Client/Server Session Key salattuna Client/TGS Session Key -avaimella.

Asiakaspalvelupyynnön vaiheet:

1. Kun asiakas vastaanottaa viestit E ja F TGS:ltä, hänellä on riittävästi tietoa todentaakseen itsensä SS:lle. Asiakas muodostaa yhteyden SS:ään ja lähettää seuraavat kaksi viestiä:
• Viesti E: edellisestä vaiheesta (asiakkaan ja palvelimen välinen lippu, joka on salattu SS-salaisella avaimella).
• Viesti G: uusi todentaja, joka sisältää asiakkaan tunnisteen, aikaleiman ja joka on salattu asiakkaan ja palvelimen istuntoavaimella.
2. SS purkaa lipun salauksen omalla salaisella avaimellaan saadakseen Client/Server Session Key -avaimen. SS purkaa istuntoavaimen avulla todentajan salauksen ja lähettää asiakkaalle seuraavan viestin vahvistaakseen todellisen henkilöllisyytensä ja halukkuutensa palvella asiakasta:
• Viesti H: asiakkaan tunnistautumislaitteesta löytyvä aikaleima plus 1, salattuna asiakkaan ja palvelimen istuntoavaimella.
3. Asiakas purkaa vahvistuksen asiakkaan ja palvelimen istuntoavaimen avulla ja tarkistaa, onko aikaleima päivitetty oikein. Jos näin on, asiakas voi luottaa palvelimeen ja voi aloittaa palvelupyyntöjen lähettämisen palvelimelle.
4. Palvelin tarjoaa asiakkaalle pyydetyt palvelut.

Haitat

• Yksi vikapiste: Keskuspalvelimen jatkuva saatavuus. Kun Kerberos-palvelin ei toimi, kukaan ei voi kirjautua sisään. Tämä voidaan ratkaista käyttämällä useita Kerberos-palvelimia ja hätätodennusmekanismeja.
• Kerberos edellyttää, että kaikkien mukana olevien isäntien kellot on synkronoitu. Lipuilla on aikavaraajakausi, ja jos isännän kelloa ei synkronoida Kerberos-palvelimen kellon kanssa, todennus epäonnistuu. Oletuskonfiguraatio edellyttää, että kellonajat ovat enintään 10 minuutin päässä toisistaan. Käytännössä kaikkien isäntien synkronointiin käytetään yleensä NTP:tä (Network Time Protocol).
• Hallintaprotokollaa ei ole standardoitu, ja se vaihtelee palvelintoteutusten välillä. Salasanojen muutokset on kuvattu RFC 3244:ssä.
• Koska kaikkien käyttäjien salaiset avaimet on tallennettu keskuspalvelimelle, palvelimen vaarantaminen vaarantaa kaikkien käyttäjien salaiset avaimet.
• Vaarantunut asiakas vaarantaa käyttäjän salasanan.

Aiheeseen liittyvät sivut

• Identiteetin hallinta
• Turvallinen etäsalasanaprotokolla (SRP)
• Yleinen turvallisuuspalvelujen sovellusohjelmaliittymä (GSS-API)