COEN 350

1. COEN 350 Kerberos

2. Kerberos • Provide authentication for a uses that works on a workstation. • Uses secret key technology for patenting reasons. • Based on work by Needham & Schroeder. • On the market in versions 4 and 5.

3. Kerberos • Kerberos consists of • Key Distribution Center (KDC) • Runs on a physically secure node • Library of Subroutines • Modifies known UNIX libraries such as telnet, rlogin, …

4. Key Distribution Center • KDC: • Database of keys for all users • Invents and hands out keys for each transaction between clients. Alice KDC Bob Alice wants Bob KAlice{ KAB for Bob } KBob{KAB for Alice}

5. Key Distribution Center • Message from KDC to Bob has some problems. • Timing problem: Alice needs to wait to make sure that Bob got the key. • Change the protocol so that Alice receives a ticket to talk to Bob.

6. Key Distribution Center Alice KDC Bob KAlice{Use KAB for Bob} Ticket for Bob := KBob{Use KAB for Bob} Alice wants Bob I’m Alice, my ticket is KBob{Use KAB for Bob}

7. Key Distribution Center • Needham Schroeder: • Combines KDC operation with authentication. • Uses nonces instead of timestamps. • A (sequential / random) number used only once.

8. Needham Schroeder N1, Alice, Bob Bob Alice KDC KAlice{N1, Bob, KAB, ticket to Bob} Ticket, KAB{N2} KAB{N2-1, N3} KAB{N3-1} Ticket = KBob{KAB, Alice}

9. Needham Schroeder N1, Alice, Bob Bob Alice Trudy (KDC) KDC Trudy as Bob KAlice{N1, Bob, KAB, ticket to Bob} Ticket = KBob{KAB, Alice}, … But the nonce makes all messages unique! Trudy can now successfully authenticate herself to Alice as Bob. Trudy impersonates the KDC and replays the old captured message, which looks like a normal message. Trudy waits until Alice makes a request to the KDC. Trudy now incorporates Bob. Purpose of the nonce is the following scenario: Assume that Trudy has stolen an old key of Bob’s and stolen the message where Alice previously has requested a key. Bob has in the meantime changed his key.

10. Needham Schroeder • Message 2: KAlice{N1, Bob, KAB, ticket} with ticket = KBob{KAB,Alice} • N1 prevents replay attacks. • “Bob” to prevent Trudy from trying to play Bob. • Ticket does not have to be sent encrypted with Alice’s key.

11. Needham Schroeder • Message 3: ticket, KAB{N2} • Alice presents a challenge together with her ticket. • Bob decodes ticket to find KAB. • He decodes the latter part of the message to find the challenge.

12. Needham Schroeder • Message 4: KAB{N2-1,N3} • Bob solves Alice’s challenge. • Bob sends Alice his own challenge. • Your turn: What is the vulnerability if message 4 were to read: KAB{N2-1}, KAB{N3} ?

13. Needham Schroeder • Answer: • Trudy eavesdrops on an exchange and then splices her own messages to Bob:

14. Needham Schroeder Bob Alice Ticket, KAB{N2} KAB{N2-1}, KAB{N3} Replays Ticket, KAB{N2} KAB{N2-1} KAB{N4} Trudy (later) Trudy now resumes her first connection: KAB{N4-1} and is authenticated Ticket, KAB{N4} KAB{N4-1} KAB{N5} Trudy (second connection)

15. Needham Schroeder • Expanded Needham Schroeder • Prevents replay attacks after Alice’s key was stolen and changed.

16. Needham Schroeder • Vulnerability Scenario • Alice has a previous key JAlice that Trudy captured. • Alice has changed her key to KAlice. • Trudy has captured a previous login request from Alice to KDC: • KDC sent JAlice{N1,Bob,JAB,KBob{JAB,Alice}}

17. Needham Schroeder • Vulnerability Scenario • Trudy has JAlice{N1,Bob,JAB,KBob{JAB,Alice}} • Trudy gets JAB and KBob{JAB,Alice} • Trudy now impersonates Alice to Bob. She sends her round 3 message N2, KBob{JAB,Alice} • She can complete the Needham Schroeder protocol. • Since the KDC no longer participates, informing the KDC of the change does not prevent Trudy from succeeding.

18. Needham Schroeder • Solution: • Prevent replays after long duration: • Clock and date. • Certificate from Bob. • Extended Needham Schroeder picks the latter.

19. Extended Needham Schroeder Alice to Bob: I want to talk to you. Bob to Alice: KBob{NB} Alice to KDC: N1, “Alice wants Bob”, KBob{NB} KDC to Alice: KAlice{N1,“Bob”,KAB, KBob{KAB, “Alice”, NB}} Alice to Bob: KBob{KAB, “Alice”, NB}, KAB{N2} Bob to Alice: KAB{N2-1,N3} Alice to Bob: KAB{N3-1}. NB prevents the previous attack. Bob can determine whether Alice is using the key that the KDC has.

20. Otway Rees • Replaces extended Needham Schroeder • Uses only 5 messages • Speed-up results from the “suspicious party” (Bob) going to the KDC.

21. Otway Rees Alice to Bob NC, “A.” “B.” KAlice{NA,NC,“A.”,“B.”} Bob to KDC KAlice{NA,NC,“A.”,“B.”} KBob{NB,NC,“A.”,“B.”} KDC to Bob NC, KAlice{NA,KAB}, KBob{NB,KAB} Bob to Alice KAlice{NA,KAB} Alice to Bob KAB{NC}

22. Kerberos • Based on Needham Schroeder, but uses time instead of nonces. • Approximate time is easy in distributed systems.

23. Kerberos • Kerberos Authentication Service: Alice to KDC N1 “Alice wants Bob” KDC to Alice KAlice{N1, “Bob”, KAB, KBob{KAB, Alice, expir. Time}} Alice to Bob KBob{KAB, “Alice”, expir. Time}, KAB{cur. Time} Bob to Alice KAB{cur. Time +1}

24. Kerberos • Kerberos Setup • Master key shared by KDC with each principal. • When Alice logs into her machine, her station asks the KDC for a session key for Alice. The KDC also gives her a Ticket Granting Ticket. (TGT) • Alice’s workstation retains only the session key and the TGT. • Alice’s workstation uses the TGT to receive other tickets from the Ticket Granting Service (TGS).

25. Kerberos • Two entities: • Key distribution center. • Authentication Server (AS) • Ticket granting server (TGS). • Both need the same database, so they are usually the same entity.

26. Kerberos • Logging in: AS Alice Workstation AS_REQ{Alice} Alice AS_REP{KAlice{SAlice,TGT}} Password? KAlice TGT = KKDC{Alice, SA} Workstation calculates session key SAlice and TGT, throws KAlice away.

27. Kerberos • Why wait for the password? • Workstation should know Alice’s password for minimum time. • Kerberos v. 5 changes this. • The workstation would contain data on which a password cracker could be run.

28. Kerberos • Purpose of TGT • AS, TGS does not need to retain session info. • Can recuperate quickly from a crash.

29. Kerberos • Remote Login • Step 1: Get a ticket for Bob. • Step 2: Use the ticket to log into Bob.

30. Kerberos Alice Workstation TGS TGS_REQ{ Alice to Bob, TGT, SA{timestamp}} rlogin Bob Gets SA from TGT, verifies timestamp, creates ticket to Bob KBob{ Alice, KAB } TGS_REP{ SA{“Bob”, KAB, KBob{Alice, KAB}}

31. Kerberos Bob Workstation AP_REQ{ KBob{Alice, KAB}, KAB{timestamp}} Bob decrypts the ticket to find KAB. He then checks the timestamp. AP_REP{ KAB {timestamp + 1}} Workstation authenticates Bob because Bob has proven he knows KAB.

32. Kerberos • After the successful rlogin, Alice and Bob are not forced to use KAB • But they can.

33. Kerberos • Replicated KDC • To remedy single point of failure. • To remedy bottleneck. • Critical design point is the master key database. • Can be made read-only at replicated KDC and updated by a single master. • Updates of the master key database need to be protected against substitution attacks.

34. Kerberos • Realms • Every entity in a Kerberos realm trusts the Kerberos TGS & AS. • Each realm has its own master key database. • Principals in one realm can be authenticated to principals in another realm.

35. Kerberos Realm 1 Alice Request and ticket for KDC in Realm 2 Realm 2 Request and ticket for KDC in Realm 3 Realm 3 Request

36. Kerberos • A single rogue KDC cannot subvert this process and grant tickets for things in other realms.

37. Kerberos • Tickets contain • Newly minted authentication key KAB • Name of requestor • Expiration Time • At most 23 hours

38. Kerberos • Keys contain version numbers. • This allows a key change without invalidating all pending requests. • Important for batch jobs when additional authentication is not possible.

39. Kerberos • Kerberos messages contain network addresses in the TGT. • The TGS checks for the network address when granting tickets.

40. Kerberos • Version 5 updates • ASN.1 data representation language • No fixed message formats. • Adds considerable overhead.

41. Kerberos • Optional delegation. • Delegation of rights allows someone to give them their access rights for a limited scope and limited time. • Cannot be done by handing out the master key, or there would be no limitation. • Kerberos v. 5 allows Alice to ask for a TGT with a network address different from her address. • This TGT is not usable by Alice, but can be used by some entity to act on Alice’s behalf.

42. Kerberos • Optional delegation. • Limited Delegation • Alice can give Bob tickets to the specific service that he will need acting on her behalf. • Instead of giving Bob a TGT. • Alice can give Bob a TGT with the AUTHORIZATION-DATA field specified. • This field is interpreted by the application, not Kerberos. • Application reads the field to determine what Bob can do. • OSF/DCE and Windows 2000 use this field extensively.

43. Kerberos • Optional Delegation • Flag in TGT indicates whether delegation is allowed: • Forwardable Flag • TGT can be exchanged for a TGT with a different network layer address. • Alice decides whether the new TGT still has the forwardable flag set. In this way, Bob can ask Carol to act for him on behalf of Alice, … • Proxiable Flag • TGT can be used to request tickets (but not TGTs) with a different network address.

44. Kerberos • Ticket Lifetimes • There is a need for longer lived tickets, but granting them in general poses security risks. • K v. 5 allows • Specifying a start time. • An end time. • Authorization time. • Renew till times.

45. Kerberos • Alice can: • Get a renewable ticket. • Ticket is valid for 100 years. • But Alice needs to renew it daily. • Renewing a ticket is done by • Giving the ticket to the KDC and have the KDC reissue it. • If there is something wrong, the KDC can be told to not renew the ticket. • KDC only needs to retain revocation data for the ticket lifetime. • Uses the renewable flag.

46. Kerberos • Alice can: • Get a postdated ticket. • Used to run a batch-job sometimes in the future. • Kerberos uses the Start-Time field to indicate the future moment when the ticket becomes valid. • Original post-dated ticket is marked invalid. • If Bob wants to use the ticket, Bob has to present it to the KDC, which clears the invalid field. • This allows revocation of postdated tickets.

47. Kerberos • Key Versions • KDC maintains versions of keys. • Stored as • key (encrypted version of Alice’s key) • p_kvno (Alice’s key version number) • k_kvno (Version of KDC key used to obtain key) • Needed for • Post-dated tickets • Renewable tickets

48. Kerberos • Making Master Keys Different • Master keys in different realms should be different, when generated with the same password. • Kerberos v.5 uses a password to key hash function that has the realm name as an additional parameter. • Keys are different in different realms in an unpredictable way.