Kerberos Authentication Systems

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