1 / 44

Kerberos Authentication Systems

Kerberos Authentication Systems. KERBEROS. In Greek mythology, a many headed dog, the guardian of the entrance of Hades (Hell). Outline. Authentication in Campus Kerberos 4 Realms (Domains) under Kerberos 4 Appendix: Kerberos 5. Authentication in Campus.

manon
Télécharger la présentation

Kerberos Authentication Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Kerberos Authentication Systems Prof. R. Aviv: Kerberos

  2. KERBEROS In Greek mythology, a many headed dog, the guardian of the entrance of Hades (Hell) Prof. R. Aviv: Kerberos

  3. Outline • Authentication in Campus • Kerberos 4 • Realms (Domains) under Kerberos 4 • Appendix: Kerberos 5 Prof. R. Aviv: Kerberos

  4. Authentication in Campus • Workstations, Servers are distributed • Users/Clients: anyone, log in at any Wstn • Servers software: examples? • need to authenticate and authorize users Can we trust Workstation software to authenticate users on behalf of servers What are the threats? Prof. R. Aviv: Kerberos

  5. Authentication in Campus • Threats: actions enabling unauthorized users to gain access to services and data • User pretend to be another user. • User alter the network address of a workstation. • User listens to exchanges and use a replay attack. How Users and Servers authenticate each other? Prof. R. Aviv: Kerberos

  6. Approaches to Authentication • Need Mutual Authentication • Workstation cannot hold policy for all servers, all computers, all users (“principals”) • Use a trusted Authentication Server - KERBEROS Server • Kerberos Server holds policy – which users can access which servers, and keys for all principals Should we use Symmetric or A-symmetric keys Prof. R. Aviv: Kerberos

  7. KERBEROS • Centralized Authentication Server • authenticating users to servers and v,v • Relies on conventional encryption • no use of public-key encryption – unlike PKI • Long term shared secrets between Kerberos and Servers and Users (not with client wstn) What are the requirements from the Kerberos Protocol? Prof. R. Aviv: Kerberos

  8. Kerberos Protocol Requirements • Partners are authenticated continuously • Partners: Client, K Servers, Server • Messages encrypted by secret short lived keys • Little user involvement Prof. R. Aviv: Kerberos

  9. Kerberos Protocol: 3 phases Server Ticket Granting Server Server Server Server 2. Authorization 3. Start service Kerberos Database Kerberos Database Workstation 1. Authentication Authentication Server Prof. R. Aviv: Kerberos

  10. Kerberos Version 4: Notation • C = Kerberos Client module (on the workstation) • AS = Kerberos Authentication Server • TGS = Ticket Granting Server • tgt= Ticket Granting Ticket • V = server (e.g. mail server, ftp server, print server) • IDU = identifier of user on C (e.g. name, email address) • IDv = identifier of server V (e.g. Server IP address+port) • PU = password of user; this is known to AS • ADc= net (IP) address of Client (user’s workstation) • Kv= secret encryption key shared by TGS and V • TS = timestamp Prof. R. Aviv: Kerberos

  11. Basic Kerberos Protocol • 1.K Client sends (User ID: IDU) and PU ? • 2. PU is known to AS. AS sends a packet with a tgt encrypted (DES); key derived from PU • Kerberos Client requests password from user • K Client decrypts packet, finding User’s ID and its own address (ADc) inside • ensuring password is PU ;user authenticated What will be the usage of tgt ? Prof. R. Aviv: Kerberos

  12. Basic Kerberos Protocol • tgt: User authenticated, allowed to get ticket • 3. K client sends tgt to the Ticket Granting Server, (TGS) is it now encrypted? • 4. K. client receives a Service Ticket,ticketv • 5. ticketv (client credentials) sent to server V • ticketv encrypted by secret known to V and TGS • tgt, ticketv have some lifetime Prof. R. Aviv: Kerberos

  13. Authenticating Phase: Once per logon • tgt is ”sealed” cannot be read by anyone but TGS (not even by User or Client); Why? • Could the ticket sent directly to TGS? • Timestamp - against replay (1) C  AS: IDU|| IDtgs (2) AS  C: EKc [tgt] what can an attacker do? tgt = EKtgs[IDU || ADc || IDtgs ||TS1 || Lifetime1] What’s the meaning of the tgt Prof. R. Aviv: Kerberos

  14. Client request and get ticketv: Once per service • IDUappears twice (also in tgt) • ADc appears twice (in IP header, and tgt) Why?Problem? • C  TGS: IDV||tgt||IDU • can attacker forge IDU? • can attacker impersonate the User? • (4) TGS  C: ticketv • ticketv = EKv[IDU || ADc || IDv ||TS2 || Lifetime2] Prof. R. Aviv: Kerberos

  15. Client getting Service: Once per service session • Server V sees its own ID --> ticketv is genuine • V compares client address in IP header & ticketv • V compares user ID in packet and ticketv Problem? (5) C  V: ticketV|| IDU ticketV = EKv[IDU|| ADC || IDV ||TS2 || Lifetime2] Prof. R. Aviv: Kerberos

  16. The Lifetime of tgt • If too short user will repeatedly enter password. • If too long, an attacker might reuse message 3 (with forged IDU, ADc) before tgt expires • Hence: Client needs to authenticate itself to TGS in its message 3 • Client adds secret authenticator to message 3 • For this Client and TGS Need a shared secret How would they get it? • AS to send a shared secret to both in message 2 Prof. R. Aviv: Kerberos

  17. New Message 2: AS sends to client a tgt, AND a shared TGS-session key to be used in message 3 tgt: login name (IDU) TGS name net address (ADc) TGS session key TGS session key Encrypted with user key Encrypted with TGS key Who knows the session key? Prof. R. Aviv: Kerberos

  18. New Message 3: Client authenticated by TGS, requests ticket • 3 parts message • tgt (previously obtained from AS), Encrypted by key known only to TGS (and AS) • authenticator: encrypted with TGS session key • Server (V) ID encrypted with TGS key tgt authenticator encrypted with TGS session key Server V Name Prof. R. Aviv: Kerberos

  19. The Lifetime of ticketv • If lifetime is long, opponent might use it • Client needs to authenticate to V in message 5 • Solution: AS gives in message 4 to both V and the K client a one time, shared session key, Kc,v • Client attach authenticator to its message 5 Prof. R. Aviv: Kerberos

  20. New Message 4: TGS sends to client a ticketvAND a shared V session key to be used in message 5 ticketv: login name IDU V name net address ADc V session key V session key Encrypted with V key Encrypted with user key Prof. R. Aviv: Kerberos

  21. New Message 5: Client authenticated by V, requests service sealed with V key ticketv authenticator sealed with V session key Server Name • 3 parts message • ticketv(previously obtained from TGS), Encrypted by key known only to V • authenticator: encrypted with V session key • Server (V) ID Prof. R. Aviv: Kerberos

  22. Phase 1: User gets ticket granting ticket, authenticate itself to Client • Authentication Service Exchange: 1. C  AS: IDU|| IDtgs ||TS1 2. AS  C: EKc [Kc,tgs|| IDtgs || TS2 || Lifetime2 || tgt] Shared Session key Prof. R. Aviv: Kerberos

  23. Phase 2: User authenticated to TGS, gets ticketv • Authenticator: Info about the Client (User name, IP Address, Timestamp) encrypted with shared secret. Expires immediately • 3. C  TGS: IDv || tgt || authenticatorc • 4. TGS  C: EKc [Kc,v|| IDv || TS4 || ticketv] • tgt = EKtgs[Kc,tgs || IDU|| ADC || IDtgs || TS2 || Lifetime2] • ticketv = EKv[Kc,v || IDU || ADC || IDV || TS4 || Lifetime4] • authenticatorc= EKc,tgs[IDU || ADc || TS3] Prof. R. Aviv: Kerberos

  24. Phase 3: Starting Service • 6. Server Authenticates itself to Client: • Server reply: TS5+1, encrypted by the shared session key (Kc,v) • 5. C  V: ticketv|| authenticatorc • V  C: EKc,v[TS5 +1] • ticketv = EKv[Kc,v || IDU || ADC || IDV || TS4 || Lifetime4] • authenticatorc = EKc,v[IDU || ADC || TS3] Prof. R. Aviv: Kerberos

  25. Summary of Kerberos 4 Protocol Prof. R. Aviv: Kerberos

  26. Realm (Domain) • A complete system is one Realm • Realm under a single administration • AS, TGS, Clients, service Servers • The TGS must share a secret key with each Server in the Realm • All Servers in a Realm register with the TGS Prof. R. Aviv: Kerberos

  27. Inter-operating Realms • Users in one realm might need access to Servers in another, interoperating realm • TGS in realms register with all other AS • AS in a realm trust other AS to authenticate its users • Servers in one realm trust TGS of the other realm Prof. R. Aviv: Kerberos

  28. User access Server RV in a remote Realm • Client applies to local AS for a Tickettgs for local TGS • 1. CAS: IDU || IDtgs || TS1 • 2. AS C: EKc[Kc,tgs || IDtgs || TS2 ||LT2||tgt] Prof. R. Aviv: Kerberos

  29. User access Server RV in a remote Realm • Client applies to local TGS for a tgtr for (remote) R-TGS • 3. C TGS: IDR-TGS || tgt || authenticatorc • 4. TGS  C: EKc,tgs[Kc,r-tgs || IDR-TGS || TS4 || tgtr] Prof. R. Aviv: Kerberos

  30. User access Server RV in a remote Realm • Client applies to RTGS for a ticketrv for RV Server • 5. C  R-TGS: IDRV || tgtr || authenticatorc • 6. R-TGSC: EKc,rtgs[Kc,rv || IDrv || TS6 || ticketrv] • Client connect to remote server • 7. C --> RV: ticketrv|| authenticatorc Prof. R. Aviv: Kerberos

  31. Prof. R. Aviv: Kerberos

  32. Appendix Kerberos Version 5 Prof. R. Aviv: Kerberos

  33. Kerberos Version 5: increased flexibility • V4: Encryption system dependence (DES) • Internet protocol dependence (IP addresses) • Flexible protocols, addresses (using tags) • V4: various Message byte ordering • V5: standard (ASN.1) • V4: Ticket lifetime limited field • V5: arbitrary start/end times Prof. R. Aviv: Kerberos

  34. Kerberos V: Delegation of Rights • Client1 requests forwardbletgt with client2 addr. • Client1 sent tgt to client2 • Client 2 requests a tgt, as if it is client1 • Client2 requests tickets to resources of client1 • E.g. print server request access to network file • Client1 requests proxiabletgt with client2 addr. • Client1 requests tickets on behalf of client2 • Client1 send tickets to client2 Prof. R. Aviv: Kerberos

  35. Kerberos V: Key in authenticator • V4: same session key can be used in two parallel sessions between client and server • attacker may replay/mix message of sessions • V5: client suggests in the authenticator a sub-session key • Server decrypts authenticator with old key, but from there on will use new key Prof. R. Aviv: Kerberos

  36. The forgetful Server: X Windows • User on workstation, with local X Server that draws on the screen • Remote application (client) commands X server • Remote & workst’n need mutual authentication: • both get tgt, then will get ticket withsession key • But User password deleted from workstation • workstation can’t decrypt packet with new tgt • can’t get ticket with new session keys Prof. R. Aviv: Kerberos

  37. Double TGT authentication • Workstation has new tgt, & previous session key • But no password to decrypt tgt packet • Remote computer requests the new tgt packet from workstation, sends both tgts to the TGS • TGS decrypts tgts, by the known passwords • Verify that 2 parties got authenticated before • re-issues the tgt packet to the workstation, this time encrypted with its old session key • Workstation decrypts, gets ticket with session key Prof. R. Aviv: Kerberos

  38. Kerberos V5: Evading dictionary attacks • V4: Actual authentication by client after receiving tgt (encrypted by user password) • Attacker gets tgt, tries all dictionary passwords • V5: request for tgt accompanied by preauthentication-data • Data: time stamp encrypted by user password • V4: Attacker request ticket for a real user • as if it is a server • Then guessing password of that user • V5: not allowing tickets for real user Prof. R. Aviv: Kerberos

  39. Version 5: Authentication Service exchange • Client request tgt. It includes realm of user, optional flags, from/till/renew times, nonce: • 1. C --> AS: Options||IDc||Realmc||IDtgs||Times||Nonce1 • AS sends tgt & block encrypted by function of password: • 2. AS > C: Realmc ||IDc|| tgt|| EKc[Kc,tgs||Times||Nonce1|| Realmtgs||IDtgs||] Prof. R. Aviv: Kerberos

  40. Version 5: Authentication Service exchange • Block: session key, same nonce, realm of TGS & ID • Nonce (encrypted) guarantees no replay • Client info also in the clear • tgt = EKtgs[Flags||Kc,tgs||Realmc||IDc||ADc|| Times] • Flags: status of ticket and options Prof. R. Aviv: Kerberos

  41. Version5: Getting Service Ticket phase • Client requests from TGS a ticketv • 3. C  TGS: Options||IDv||Times||Nonce2||tgt||MACc • 4. TGS  C: Realmc||IDc||ticketv|| EKc,tgs [Kc,v||Times||Nonce2|| Realmv ||IDv] • Session key is carried in both ticket and block • Realm v is provided to C • block encrypted by the session key EKc,tgs Prof. R. Aviv: Kerberos

  42. Version5: Getting Service Ticket phase • Tickettgs = EKtgs[Flags||Kc,tgs||Realmc||IDc||ADc|| Times] • ticketv = EKv[Flags||Kc,v||Realmc||IDc||ADc|| Times] • MACc = EKc,tgs[IDc|| Realmc ||TS1] Prof. R. Aviv: Kerberos

  43. Version 5: starting Service phase • 5. CV: Options||ticketv||MACc • 6. VC: EKc,v[TS2||Subkey||Seq#] • One-session sub-key may be created by client, carried to server in MAC • Similarly for sequence number that will be used by server • ticketv = EKv[Flags||Kc,v||Realmc||IDc||ADc|| Times] • MACc = EKc,v[IDc|| Realmc ||TS2||Subkey||Seq#] Prof. R. Aviv: Kerberos

  44. Summary • Authentication in Campus provided by a central authority • Authentication is integrated with Authorization • Authentication is provided by reusable series of tickets • Protocol exchanges are protected by authenticators using one time session keys • System provides for delegation of authentication Prof. R. Aviv: Kerberos

More Related