COEN 350

1. COEN 350 Kerberos

2. Kerberos • Provide authentication for a user that works on a workstation. • Uses secret key technology • Because public key technology still had patent projection. • Implements authentication 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 Alice} Alice wants Bob I’m Alice, my ticket is KBob{Use KAB for Alice}

7. Key Distribution Center • Needham Schroeder: • Combines KDC operation with authentication. • Uses nonces instead of timestamps to prevent replay attacks. • 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 nonces make 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} ? Answer on next two slides.

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 master key was stolen and Alice changed her master key.

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 calculates JAB and KBob{JAB,Alice} with JAlice. • Trudy now impersonates Alice to Bob. She sends her round 3 message to Bob: N2, KBob{JAB,Alice} • She can complete the Needham Schroeder protocol with Bob. • Since the KDC no longer participates, informing the KDC of the change does not prevent Trudy from succeeding impersonating Alice to Bob.

18. Needham Schroeder Vulnerability Scenario • Trudy has • JAlice{N1,Bob,JAB,KBob{JAB,Alice}}, JAB. KBob{JAB,Alice}. • Trudy to Bob: JAB{N2}, KBob{JAB,Alice} • Bob to Trudy: JAB{N2–1, N3} • Trudy to Bob: JAB{N3–1} • Trudy and Bob are mutually authenticated!

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

20. 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.

21. Extended Needham Schroeder • Alice now needs to receive a certificate from Bob before starting standard Needham Schroeder.

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

23. Otway Rees Alice to Bob: NC, Alice Bob KAlice{NA,NC,“A.”,“B.”} Bob to KDC: KAlice{NA,NC, Alice, Bob, 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}

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

25. 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}

26. 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).

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

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

29. 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.

30. Kerberos • Kerberos V. 5 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.

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

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

33. 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}}

34. Kerberos Bob A’s 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.

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

36. 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.

37. 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.

38. 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

39. Kerberos • Realms V4: • Principal names have three strings: • NAME • service • INSTANCE • typically server on which service runs • REALM • Version 5: Uses ASN.1 • NAME • now arbitrary number of fields • Realm

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

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

42. Kerberos • Keys contain version numbers. • Network resources (incl. KDC) remember several versions of their master keys. • This allows a key change without invalidating all pending requests. • Important for batch jobs when additional authentication is not possible.

43. Kerberos • Encryption is used to prevent disclosure and modification. • Key: Cannot be disclosed nor modified • Name: cannot be modified. • Version 4: Proprietary system with a few flaws • Plaintext Cipher Block Chaining

44. Kerberos: PCBC • Modifying any Ci results in modifying all subsequent Ci. • At end of message, put in something recognizable. • Flaw: Swapping to adjacent blocks, subsequent blocks are back in order.

45. Kerberos • Kerberos V. 4 uses a checksum mechanism for integrity. • Algorithm is suspect, but not proven broken. • Kerberos V. 5 uses a suite of possible checksum algorithms

46. Kerberos • Kerberos messages contain network addresses in the TGT. • The TGS checks for the network address when granting tickets. • This is not much of a protection • It is easy to fake network addresses • But together with a firewall might be useful to thwart attackers from outside.

47. Kerberos • Kerberos puts 4B IPv4 address inside a ticket. • Recipient of ticket checks whether the source IP address is the same as in the ticket. • Prevents use of a stolen session key and TGT. • Probably not worth the trouble, since it is easy to spoof IP addresses. • Generates problems with NAT. • Makes delegation of rights difficult / impossible.

48. Kerberos • Version 5 updates • ASN.1 data representation language • No fixed message formats. • Adds considerable overhead. ASN.1 is presented in COEN 351.

49. Kerberos • Optional delegation of Rights: • Delegation of rights allows someone to give them their access rights for a limited scope and limited time. • Important to allow access to resources by a long-lasting batch-job. • Cannot be done by handing out the master key, or there would be no limitation to the delegation. • Handing tickets to the batch-job will not work if they are used after they expire.

50. Kerberos • Optional delegation. • 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.