1. Winter 2006Prof. R. Aviv: Kerberos1 Kerberos Authentication Systems

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

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

4. Winter 2006Prof. R. Aviv: Kerberos4 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?

5. Winter 2006Prof. R. Aviv: Kerberos5 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?

6. Winter 2006Prof. R. Aviv: Kerberos6 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

7. Winter 2006Prof. R. Aviv: Kerberos7 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?

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

9. Winter 2006Prof. R. Aviv: Kerberos9 Kerberos Protocol: 3 phasesServerServer ServerServer ServerServer KerberosDatabase ServerServer KerberosDatabase Ticket Granting Server Server Ticket Granting Server Server Authentication Authentication WorkstationWorkstation 1. Authentication 2. Authorization 3. Start service

10. Winter 2006Prof. R. Aviv: Kerberos10 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) ID U = identifier of user on C (e.g. name, email address) ID v = identifier of server V (e.g. Server IP address+port) P U = password of user; this is known to AS ADc = net (IP) address of Client (user’s workstation) K v = secret encryption key shared by TGS and V TS = timestamp

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

12. Winter 2006Prof. R. Aviv: Kerberos12 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, ticket v 5. ticket v (client credentials) sent to server V ticket v encrypted by secret known to V and TGS tgt, ticket v have some lifetime

13. Winter 2006Prof. R. Aviv: Kerberos13 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: ID U || ID tgs (2) AS  C: E Kc [tgt] what can an attacker do? tgt = E K tgs [ID U || AD c || ID tgs ||TS 1 || Lifetime 1 ] What’s the meaning of the tgt

14. Winter 2006Prof. R. Aviv: Kerberos14 Client request and get ticket v : Once per service ID U appears twice (also in tgt) ADc appears twice (in IP header, and tgt) Why? Problem? (3)C  TGS: ID V ||tgt ||ID U can attacker forge IDU? can attacker impersonate the User? (4) TGS  C: ticket v ticket v = E K v [ID U || AD c || ID v ||TS 2 || Lifetime 2 ]

15. Winter 2006Prof. R. Aviv: Kerberos15 Client getting Service: Once per service session Server V sees its own ID --> ticket v is genuine V compares client address in IP header & ticket v V compares user ID in packet and ticket v Problem? (5) C  V: ticket V || ID U ticket V = E K v [ID U || AD C || ID V ||TS 2 || Lifetime 2 ]

16. Winter 2006Prof. R. Aviv: Kerberos16 The Lifetime of tgt If too short user will repeatedly enter password. If too long, an attacker might reuse message 3 (with forged ID U, 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

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

18. Winter 2006Prof. R. Aviv: Kerberos18 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 tgt authenticator Server V Name encrypted with TGS key encrypted with TGS session key

19. Winter 2006Prof. R. Aviv: Kerberos19 The Lifetime of ticket v 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, K c,v –Client attach authenticator to its message 5

20. Winter 2006Prof. R. Aviv: Kerberos20 New Message 4: TGS sends to client a ticket v AND a shared V session key to be used in message 5 V session key ticket v : login name ID U V name net address AD c V session key Encrypted with user key Encrypted with V key

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

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

23. Winter 2006Prof. R. Aviv: Kerberos23 Phase 2: User authenticated to TGS, gets ticket v Authenticator: Info about the Client (User name, IP Address, Timestamp) encrypted with shared secret. Expires immediately 3. C  TGS: IDv || tgt || authenticator c 4. TGS  C: EKc [Kc,v|| IDv || TS4 || ticket v ] tgt = EK tgs [Kc,tgs || ID U || AD C || ID tgs || TS2 || Lifetime2] ticket v = EKv[Kc,v || ID U || AD C || ID V || TS4 || Lifetime4] authenticator c = EKc,tgs[ID U || ADc || TS3]

24. Winter 2006Prof. R. Aviv: Kerberos24 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: ticket v || authenticator c 6.V  C: EKc,v[TS5 +1] ticket v = EKv[Kc,v || ID U || AD C || ID V || TS4 || Lifetime4] authenticator c = EKc,v[ID U || AD C || TS3]

25. Winter 2006Prof. R. Aviv: Kerberos25 Summary of Kerberos 4 Protocol

26. Winter 2006Prof. R. Aviv: Kerberos26 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

27. Winter 2006Prof. R. Aviv: Kerberos27 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

28. Winter 2006Prof. R. Aviv: Kerberos28 User access Server R V in a remote Realm  Client applies to local AS for a Ticket tgs for local TGS 1. C  AS: ID U || ID tgs || TS 1 2. AS  C: E Kc [K c,tgs || ID tgs || TS 2 ||LT 2 ||tgt]

29. Winter 2006Prof. R. Aviv: Kerberos29 User access Server R V in a remote Realm  Client applies to local TGS for a tgt r for (remote) R-TGS 3. C  TGS: ID R-TGS || tgt || authenticator c 4. TGS  C: E Kc,tgs [K c,r-tgs || ID R-TGS || TS 4 || tgt r ]

30. Winter 2006Prof. R. Aviv: Kerberos30 User access Server R V in a remote Realm  Client applies to RTGS for a ticket rv for R V Server 5. C  R-TGS: ID RV || tgt r || authenticator c 6. R-TGS  C: E Kc,rtgs [K c,rv || ID rv || TS 6 || ticket rv ]  Client connect to remote server 7. C --> RV: ticket rv || authenticator c

31. Winter 2006Prof. R. Aviv: Kerberos31

32. Winter 2006Prof. R. Aviv: Kerberos32 Appendix Kerberos Version 5

33. Winter 2006Prof. R. Aviv: Kerberos33 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

34. Winter 2006Prof. R. Aviv: Kerberos34 Kerberos V: Delegation of Rights Client1 requests forwardble tgt 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 proxiable tgt with client2 addr. –Client1 requests tickets on behalf of client2 –Client1 send tickets to client2

35. Winter 2006Prof. R. Aviv: Kerberos35 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

36. Winter 2006Prof. R. Aviv: Kerberos36 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 with session key –But User password deleted from workstation –workstation can’t decrypt packet with new tgt – can’t get ticket with new session keys

37. Winter 2006Prof. R. Aviv: Kerberos37 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

38. Winter 2006Prof. R. Aviv: Kerberos38 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

39. Winter 2006Prof. R. Aviv: Kerberos39 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||Realm c ||ID tgs ||Times||Nonce 1  AS sends tgt & block encrypted by function of password:  2. AS > C: Realm c ||IDc|| tgt || E Kc [Kc,tgs||Times||Nonce 1 || Realm tgs ||ID tgs ||]

40. Winter 2006Prof. R. Aviv: Kerberos40 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 = E Ktgs [Flags||Kc,tgs||Realm c ||IDc||ADc|| Times]  Flags: status of ticket and options

41. Winter 2006Prof. R. Aviv: Kerberos41 Version5: Getting Service Ticket phase Client requests from TGS a ticket v –3. C  TGS: Options||IDv||Times||Nonce 2 ||tgt||MAC c –4. TGS  C: Realm c ||IDc||ticket v || E Kc,tgs [K c,v ||Times||Nonce 2 || Realm v ||IDv] –Session key is carried in both ticket and block –Realm v is provided to C –block encrypted by the session key E Kc,tgs

42. Winter 2006Prof. R. Aviv: Kerberos42 Version5: Getting Service Ticket phase Ticket tgs = E Ktgs [Flags||Kc,tgs||Realm c ||IDc||ADc|| Times] ticket v = E Kv [Flags||Kc,v||Realm c ||IDc||ADc|| Times] MAC c = E Kc,tgs [IDc|| Realm c ||TS 1 ]

43. Winter 2006Prof. R. Aviv: Kerberos43 Version 5: starting Service phase 5. C  V: Options||ticket v ||MAC c 6. V  C: E Kc,v [TS 2 ||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 ticket v = E Kv [Flags||Kc,v||Realm c ||IDc||ADc|| Times] MAC c = E Kc,v [IDc|| Realm c ||TS 2 ||Subkey||Seq#]

44. Winter 2006Prof. R. Aviv: Kerberos44 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