1 / 28

Kerberos

Kerberos. Kerberos. Trusted key server system from MIT Based on Needham-Shroeder Signifies multi-headed dog in Greek mythology (keep outsiders away) provides centralised private-key third-party authentication in a distributed network

bjanice
Download Presentation

Kerberos

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

  2. Kerberos • Trusted key server system from MIT • Based on Needham-Shroeder • Signifies multi-headed dog in Greek mythology (keep outsiders away) • provides centralised private-key third-party authentication in a distributed network • allows users access to services distributed through network • without needing to trust all workstations • rather all trust a central authentication server • two versions in use: 4 & 5

  3. Kerberos Requirements • first published report identified its requirements as: • security • reliability • transparency • scalability • implemented using an authentication protocol based on Needham-Schroeder

  4. Kerberos Realms • a Kerberos environment consists of: • a Kerberos server • a number of clients, all registered with server • application servers, sharing keys with server • this is termed a realm • typically a single administrative domain • if have multiple realms, their Kerberos servers must share keys and trust

  5. Kerberos 4 Overview • a basic third-party authentication scheme • have an Authentication Server (AS) • users initially negotiate with AS to identify self • AS provides a non-corruptible authentication credential (ticket granting ticket TGT) • have a Ticket Granting server (TGS) • users subsequently request access to other services from TGS on basis of users TGT

  6. Tickets and Ticket-Granting Tickets • users, resources: principal share master key with KDC • KDC sends to A: KA{KAB} • Bob ; ticket: KB{KAB} + other information (name of Alice) • Alice tickets expire in 21 hours • thus: knowledge of KAB proves identity + use for encryption • credentials: KAB and ticket

  7. Alice logs in with uid and passwd • password generates master key • workstation asks for session key SA on behalf of Alice (time-limited) • KDC sends SAto workstation • ticket-granting ticket (TGT) KDC{SA ….}master key • workstation uses Alice’s master key to decrypt SA • Then workstation forgets master key, uses TGT • KDC: authentication server (AS) + ticket-granting server (TGS)

  8. Configuration • KDC master key encrypts KDC database, TGT – Kerberos server • DES-based • principals need to remember password (humans) or key (machines) • KDC  database of names of all principals for which it is responsible

  9. How does Kerberos Work • Four parties involved • Alice : client workstation • Authentication Server (AS) : Verifies the user during login ; shares unique passwd with every user • Ticket Granting Server (TGS) : Issues tickets to certify proof of identity • Bob : server offerings services such as network printing, file sharing or an application program

  10. Step 1 • Alice on public workstation enter the name • Workstation sends plain text name to AS • AS performs several actions • Creates package of username & random session key(KS) encrypted with the key shared between AS and TGS  TGT • (TGT and KS ) encrypted using symmetric key derived from the passwd of Alice(KA) AS Alice Login Id = Alice

  11. AS sends back encrypted session key and TGT to Alice AS Alice Output* Alice Session key (KS) Symmetric key shared with the Ticket Granting Server (TGS) Encrypt Session key (KS) TGT AS computes the output as shown below and sends it to Alice in response to her login request. KS+TGT Symmetric key derived from Alice’s password (KA) Encrypt Output*

  12. Step 2 : Alice sends a request for SGT to the TGS • Contains TGT, id of server (Bob)& current timestamp encrypted with session key TGS Alice Request for a SGT Output* Timestamp Session key (KS) Encrypt AS computes the output as shown below and sends it to the TGS. Encrypted Timestamp (ET) TGT Bob Output*

  13. TGS Alice Output* KAB Alice Encrypt B’s secret key KAB Bob Encrypt Session Key (KS) Output* • TGS sends response back to Alice

  14. Step 3 • User contacts Bob for accessing the server • Alice sends KAB securely to Bob Bob Alice Sending KAB Output* Timestamp Alice had received this from the TGS in the previous step Secret key to be shared by Alice and Bob (KAB) Encrypt Encrypted Timestamp (ET) (Alice + KAB) encrypted with Bob’s secret key Output* SendingKAB

  15. Bob Alice Encrypted Timestamp (ET)* Timestamp sent by Alice. First add 1 to it. Secret key shared by Alice and Bob (KAB) Encrypt Encrypted Timestamp (ET)* • Bob acknowledges the receipt of KAB Acknowledging KAB

  16. Kerberos 4 Overview

  17. Replicated KDCs • KDC: single PoF (in addition to NFS. . . ) • replication with master copy (multiple KDC) • One site holds the master copy updates can be done (still POF) but KDC is normally read only • performance scaling: service location protocol? • exchange master database in clear, protected by secure hash • Avoid bottleneck

  18. Realms • can’t have single (replicated) KDC: need to limit trust • limit compromise • Principals are divided into realms each having a KDC • each realm carries others as principals • principal: name (service), instance (host, human role), realm • no chaining of realms: prevent rogue KDC impersonating everybody • V4: DNS names

  19. Interrealm Authentication • N realms • The principals in one realm need to authenticate one in others. • Supported by Kerberos • The KDC in realm B can be registered as a principal in realm A • V4 does not support chaining of KDC’s

  20. TGS_REQ(“alice@Wonderland”,Oz@wonderland Wonderland KDC Credentials to Oz Oz KDC Alice Dorothy TGS_REQ(“alice@Wonderland”,Dorothy@Oz Credentials to Dorothy AP _ REQ Interrealm Authentication

  21. Key Version Numbers • allow unsynchronized changes of master keys • remember several versions of past keys • replication  new passwords may fail

  22. Kerberos Version 5 • developed in mid 1990’s • provides improvements over v4 • addresses environmental shortcomings • encryption algo, network protocol, byte order, ticket lifetime, authentication forwarding, interrealm auth • and technical deficiencies • double encryption, non-std mode of use, session keys, password attacks • specified as Internet standard RFC 1510

  23. Names • Kerberos V4 client is named by three fields • Name, instance, realm • V%  2 components • Realm and name

  24. Delegation of Rights • transfer rights to object, for limited time & scope • can’t delegate: contain network address of requestor • V5: ask for TGT for different node or any node (audit!) • may grant TGT or ticket to specific service • Forwardable: exchange for TGT with different address • may ask for TGT that can again be forwarded • Proxy tickets

  25. Ticket Lifetimes • unlimited lifetime instead of 21 hours • – start time (may be postdated into the future) • – end time (may be adjusted) • – authorization time (initial TGT) • – renew-till = upper bound on renewal • – postdating may require revalidation à revocation • renewable ticket • can’t renew expired ticket

  26. Key Protection • single password in all realms à same masterkey • compromise one KDC à compromise all • solution: master key depends on realm

  27. Cryptographic Algorithms V4: DES only  export-controlled, limited security V5: algorithm indication, but not negotiation only as secure as weakest algorithm accepted should use MD (secret / message)

  28. Hierarchy of Realms • V4: each realm must be registered in “origin” realm • V5: allow chaining  e.g., Alice in A talk to Carol in C; C not registered in A • B registered in A, C in B • allows realm B to impersonate anybody • list transit domains (reject if KDC named doesn’t match key) • trust: transit or for principals • realm tree: share key with parents, children • allow only shortest path through tree (lowest common ancestor) • identify tree based on names (domain hierarchy) • cross links as shortcuts

More Related