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

4. Winter 2006Prof. R. Aviv: Kerberos4 Authentication in Campus Workstations, Servers are distributed Users/Clients: anyone, log in at any Wstn Servers software: – 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 users why not? –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 between Kerberos Server and others encrypted by secret short lived keys Little user involvement

9. Winter 2006Prof. R. Aviv: Kerberos9 Kerberos Protocol: 3 phasesServerServer ServerServer ServerServer KerberosDatabase Print Server KerberosDatabase Ticket Granting Server (TGS) Server (TGS) Ticket Granting Server (TGS) Server (TGS) Authentication Server (AS) Server (AS)Authentication Workstation: K Client Workstation: 1. Authentication 2. Authorization 3. Start service Assume user wants to print

10. Winter 2006Prof. R. Aviv: Kerberos10 Kerberos Version 4: Items/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, known to AS ADc = network 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 back a packet with 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, in correct format –ensuring user knows 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|| ID U ] 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 where? ADc appears twice where 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: TGS must authenticate Client again –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 authenticates itself to 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, attacker might reuse it How? V must authenticate the Client again 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 authenticates itself to 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, and Client Authenticates the User 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: TGS authenticates User, User 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: V Server, User authenticate each other, User gets service 6. Client Authenticate the Server: –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) Organization is organized in Realms (Domains) A Realm (e.g. faculty) under a single admin –Includes: AS, TGS, Clients, service Servers The TGS must share a secret key with each Server in its 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 example? 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