Kerberos Kerberos Trusted key server system from MIT

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 n allows users access to services distributed through network n without needing to trust all workstations n rather all trust a central authentication server two versions in use: 4 & 5

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

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

Kerberos 4 Overview a basic third-party authentication scheme have an Authentication Server (AS) n n 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) n users subsequently request access to other services from TGS on basis of users TGT

Tickets and Ticket-Granting Tickets users, resources: principal share master key with 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

Alice logs in with uid and password generates master key workstation asks for session key SA on behalf of Alice (time-limited) KDC sends SA to 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) + ticketgranting server (TGS)

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

How does Kerberos Work Four parties involved n n 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

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) Alice Login Id = Alice AS

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

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

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

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

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

Kerberos 4 Overview

Replicated KDCs KDC: single Po. F (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

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 principal: name (service), instance (host, human role), realm no chaining of realms: prevent rogue KDC impersonating everybody V 4: DNS names

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 V 4 does not support chaining of KDC’s

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

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

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

Names Kerberos V 4 client is named by three fields n Name, instance, realm V% 2 components n Realm and name

Delegation of Rights transfer rights to object, for limited time & scope can’t delegate: contain network address of requestor V 5: 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

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

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

Cryptographic Algorithms V 4: DES only export-controlled, limited security V 5: algorithm indication, but not negotiation only as secure as weakest algorithm accepted should use MD (secret / message)

Hierarchy of Realms V 4: each realm must be registered in “origin” realm V 5: 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