Vous êtes sur la page 1sur 40

Kerberos

mr Goran Đorđević, dipl.inž.


dr Milan Marković, dipl.inž.
Autentikacioni protokol:
Kerberos

U Grčkoj mitologiji, pas sa više glava, čuvar ulaza u


pakao
Šta je Kerberos?
• Razvio ga MIT(Massachusetts Institute of
Technology).
• Deljena tajna – autentikacija se bazira se
učešću treće strane od poverenja.
• Omogućava single sign-on.
• Lozinke (password) se nikad ne šalju
otvoreno preko mreže.
Pretnje u distribuiranom okruženju
• Kerberos je razvijen kao deo Athena projekta
na MIT univerzitetu.
• Athena predstavlja mrežu radnih stanica i
distribuiranih ili centralizovanog servera.
 Potencijalne pretnje u mrežnom okruženju:
 Lažno predstavljanje korisnika,
 Korisnik može da lažira IP adresu radne stanice,
 Korisnik može da nadgleda saobraćaj i da vrši
retransmisiju ranije poslatih paketa.
Kerberos 4: pregled
• Autentikacioni protokol sa aktivnom
trećom stranom od poverenja
 Komponente:
 Autentikacioni server (AS):
 Korisnik se identifikuje autentikacionom serveru.
 Autentikacioni server generiše autentikaciona
uverenja (credential) TGT (Ticket Granting Ticket).

 Ticket-Granting Server
 Daje dozvolu korisniku za pristup servisima u
mrežnom okruženju.
Ticket
Granting
XYZ Servis Koristi se termin “Kerberos Service
Server”

Key
Distribution
Center

Authen-
Tication
Service

Desktop
računar
Korisnik A Korisnika A
Ticket
Granting
XYZ Servis Predstavlja resurs koji Service
zahteva Kerberos
autentikaciju (web
server, ftp server, ssh Key
server, itd…) Distribution
Center

Authen-
Tication
Service

Desktop
računar
Korisnik A Korisnika A
Ticket
Granting
XYZ Service Service

Key
“Tražim dozvolu da Distribution
dobijem ticket sa Ticket Center
Granting Server“.

Authen-
Tication
Service

Desktop
računar
Korisnik A Korisnika A
Ticket
Granting
XYZ Service Service
“U redu. Zaključao sam dati
paket sa tvojom lozinkom.
Ukoliko ga otključaš, možeš da
Key
koristiš njegov sadržaj da bi
Distribution
pristupio Ticket Granting
Center
Service.”

Authen-
Tication
Service

Desktop
računar
Korisnik A Korisnika A
Ticket
Granting
XYZ Service Service

Key
Distribution
Center

Authen-
Tication
TGT Service

Desktop
računar
Korisnik A Korisnika A
Nakon što Korisnik A otvori paket (dešifruje
poruku) dobijenu od Authentication Service,
TGT on pristupa “Ticket-Granting Ticket”.

Da bi se dobio “Service tickets” Ticket-


Granting Ticket (TGT) mora da se
prezentuje Ticket Granting Service.
“Service tickets” zahteva servis u cilju
omogućavanja pristupa njegovim
resursima.

TGT ne sadrži lozinku.


“Potvrđujem ja sam
Korisnik A i želim da Ticket
pristupim XYZ Service. Granting
XYZ Service Service
Ovo je moj TGT!”

Key
Distribution
Center

Authen-
TGT Tication
TGT
Service

Desktop
računar
Korisnik A Korisnika A
XYZ:
Korisnik A is Korisnik A. Ticket
POTVRĐUJE: TGS
Granting
XYZ Service Service
Ti si korisnik A.
Šaljem ti ticket
Key
Distribution
Center

Authen-
Tication
TGT
Service

Desktop
računar
Korisnik A Korisnika A
Ticket
Granting
XYZ Service Ja sam korisnik A. Service
Ovde je kopija service
ticket-a za XYZ.
Key
Distribution
Center

Authen-
XYZ:
XYZ: Tication
Korisnik A je
Korisnik A je TGT
Korisnik A.
Korisnik
POTVRĐUJE: TGS A. Service
POTVRĐUJE: TGS

Desktop
računar
Korisnik A Korisnika A
To je Korisnik A. Potrebno je
da utvrdi da li je autorizovan
Ticket
da koristi resurse.
Granting
XYZ Service Service

XYZ:
Korisnik A je Korisnik A. Key
POTVRĐUJE: TGS Distribution
Center

Authen-
XYZ:
Tication
Korisnik A je Korisnik A. TGT
POTVRĐUJE: TGS Service

Desktop
računar
Korisnik A Korisnika A
Provera autorizacije realizuje XYZ service…

Činjenica da je Korisnik A autentikovan


automatski ne znači da je autorizovan da koristi
odgovarajuće resurse XYZ service.
Primedba:

Ticktet-i (TGT i service ticket) imaju vreme isteka


koje je konfiguriše lokalni sistem administrator.
Ticket koji je istekao je neupotrebljiv.

Sve dok je tiken validan (tj. dok ne istekne)


moguće ga je višetsruko koristiti.
Ticket
Ponovni pristup Granting
XYZ Service Service
Korisnika A. Ovde je
kopija service ticket-a za
XYZ.
Key
Distribution
Center

Authen-
XYZ:
Korisnik A XYZ: Tication
Korisnik A is Korisnik TGT
is Korisnik A.
POTVRUJE: TGS A. Service
POTVRUJE: TGS

Desktop
računar
Korisnik A Korisnika A
Ponovni pristup Korisnik A…
Provera da li je Korisnik A
autorizovan za pristup Ticket
resursima. Granting
XYZ Service Service

XYZ:
Korisnik A je Korisnik A. Key
POTVRĐUJE: TGS Distribution
Center

Authen-
XYZ:
Tication
TGT
Korisnik A je Korisnik A.
POTVRĐUJE: TGS Service

Desktop
računar
Korisnik A Korisnika A
Overview of Kerberos
Kerberos Terms & Abbreviation
• Kerberos realm consists of
– a Kerberos server
• Authentication Server (AS)
• Ticket Granting Server (TGS)
– Users and servers that are registered with Kerberos
server
• Uses ticket
– Ticket granting Ticket, TGT (issued by AS for user to
request for service ticket from TGS)
– Service Ticket (issued by TGS for user to use service
from server)
How Does it Work?
• Initial Authentication
– 1. Authenticate
– 2. Receive TGT
• Using TGT
– 3. Request Service Ticket
– 4. Receive Service Ticket
– 5. Get Service
How Does it Work?
Kerberos 4
Kerberos 5
Note
• Authentication is by password
• User’s password is never transmitted
• User’s knows their own password & Kerberos
Server has a copy stored in it’s database in
encrypted form
• Password is used to encrypt the Ticket Granting
Ticket to secure from eavesdropper.
Kerberos Version 5
• Better user-server authentication
– Separate subkey for each user-server session instead
of reusing the session key contained in the ticket
– Authentication via subkeys, not timestamp increments
• Authentication forwarding (delegation)
– Servers can access other servers on user’s behalf,
e.g., can tell printer to fetch email
• Realm hierarchies for inter-realm authentication
• Explicit integrity checking + standard CBC mode
• Multiple encryption schemes, not just DES
Why the Change?
• Kerberos 4 was designed to minimize the
amount of time the user’s password is stored on
the workstation. Kerberos server doesn’t check if
user is who he says he is.
• Attacker can intercept the encrypted TGT and
mount a dictionary attack to guess the
password.
• Kerberos 5 is more secure. Kerberos server
makes sure that user’s password is valid before
sending the TGT back to the user.
What is Ticket Granting Ticket
• A block of data that contains:
– Session key : Kses
– Ticket for TGS which is encrypted with both the
session key and the Ticket Granting Server’s Key
Ktgs{Kses{Ttgs}}
• User’s workstation can now contact the
Kerberos TGS to obtain tickets for any services
within the Kerberos realm.
Using the Ticket Granting Ticket

• Service Ticket is another ticket, Tx encrypted by File


Server’s Key, Kfs{Tx}
• Tx contains UID, IPaddr, expiration time.
How is identity established
• TGS can establish user identity because the
request is encrypted using the session key
(available only if user can decrypt the TGT from
the AS)
• File Server Service can establish user’s identity
because the ticket (encrypted with File Server
Service’s key) contains the user’s info – put in
there by TGS.
Kerberos 5
• Kerberos 5 is more resistant to determined
attacks over the network.
• More flexible – can work with different kinds of
networks
• Supports delegation of authentication
• Longer ticket expiration time
• Renewable tickets.
Kerberos Limitations
• Every network service must be individually
modified for use with Kerberos
• Doesn’t work well in time sharing environment
• Requires a secure Kerberos Server
• Requires a continuously available Kerberos
Server
• Stores all passwords encrypted with a single key
• Assumes workstations are secure
• May result in cascading loss of trust.
• Scalability
Kerberos Autentikacija
• Računari: Klijent, KDC, Aplikativni Server
• KDC je domenski kontroler (domain
controller)
• Podrazumeva postojanje napadača na
mreži.
• Data prezentacija uključuje jedan realm
(domen).
Keš (Cache)
• Korisnička ovlašćenja su keširana u
HKEY_LOCAL_MACHINE\Security\Cache
kao hash vrednost password-a
• Tiketi su smešteni u non-paged
memorijskoj sekciji i brišu se kada se
korisnik odjavi (logg off) ili kada se računar
ugasi (shuts down).
Smart Card logon
1. Nakon što korisnik ubaci smart karticu, Windows logon service
(WINLOGON) prosleđuje zahtev ka GINA
2. Od korisnika se zahteva unos PIN koda.
3. GINA modul šalje PIN ka Local Security Authority (LSA) modulu
4. LSA modul, koristeći PIN kod, pristupa smart kartici i vrsi eksportovanje
korisničkog sertifikata i javnog ključa. Korisnički sertifikat se dodatno
digitalno potpisuje sa korisničkim privatnim ključem
5. Kerberos security service provider šalje korisnički sertifikat (sa dodatnim
digitalnim potpisom (vidi tacku 4)) ka KDC
6. KDC modul upoređuje polje UPN iz sertifikata sa korisničkim objektom u
Aktivnom Direktorijumu. KDC takodje verifikuje potpis sertifikata (mora biti
potpisan sa CA telom kome Aktivni Direktorijum veruje - trustedCA)
7. KDC šifruje logon sesijski ključ i TGT (koristi se za pristup Ticket Granting
Service) sa javnim ključem korisnika (koji se izdvaja iz sertifikata). (Ovde
se de facto primenjuje sistem digitalne envelope)
8. Klijent vrši dešifrovanje logon sesijskog ključa i šalje TGT ka Ticket
Granting Service-u
Windows Smart Card Logon overview
1. When the user inserts the smart card or token, Windows prompts for a Personal
Identification Number (PIN) in a logon window.
2. The smart card subsystem authenticates the user as the owner of the smart card
or token, and retrieves the certificate from the card.
3. The smart card client software sends the certificate to the Kerberos Key
Distribution Center (KDC) on the Domain Controller.
4. The KDC verifies the Smart Card Logon certificate by building a certificate chain
until it finds the root CA certificate. During the verification process, each certificate
in the chain is checked against the Certification Revocation List (CRL) in the CRL
Distribution Point (CDP).
5. The KDC retrieves the UserPrincipalName (UPN) from the subjectAltName of the
Smart Card Logon certificate, and uses it as a reference to look up the user entry
in the directory.
6. The KDC builds a Kerberos ticket-granting ticket (TGT), which contains the user
account and access control information.
7. The KDC encrypts the TGT with a session key, encrypts that key with the user’s
public key, and returns the encrypted TGT to the user’s workstation.
8. The smart card decrypts the session key with its private key, and uses the
session key to decrypt the TGT. At this point, the KDC lets the user log in to the
Windows domain.
HVALA NA PAŽNJI

Vous aimerez peut-être aussi