1 / 48

COEN 350

COEN 350 . Kerberos. 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. Kerberos. Kerberos consists of Key Distribution Center (KDC)

nadda
Download Presentation

COEN 350

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related