Kerberos

1. Kerberos

2. Assume an open distributed environment in which users at workstations wish to access services on servers distributed throughout the network.

3. Threats: • A user may gain access to a particular workstation and pretend to be another user operating from that workstation. • A user may eavesdrop on exchanges and use a reply attack to gain entrance to a server or to disrupt operations. • A user may alter the network address of a workstation so that the requests sent from the altered workstation appear to come from the impersonated workstation.

4. Kerberos: • A secret key based service for providing authentication in open networks • Authentication mediated by a trusted 3rd party on the network: • Key Distribution Center (KDC)

5. Key Distribution • At many points so far, we have run into problems with using cryptography for network security. • How can we securely store and distribute key and password information? • How can we certify that keys and password are safe and to be trusted? • To solve these issues, we make use of a variety of trusted intermediaries.

6. Trusted Intermediaries Symmetric key problem: • How do two entities establish shared secret key over network? Solution: • trusted key distribution center (KDC) acting as intermediary between entities Public key problem: • When Alice obtains Bob’s public key (from web site, e-mail, diskette), how does she know it is Bob’s public key, not Trudy’s? Solution: • trusted certification authority (CA)

7. KB-KDC KX-KDC KY-KDC KZ-KDC KP-KDC KB-KDC KA-KDC KA-KDC KP-KDC Key Distribution Centers (KDCs) • Alice, Bob need shared symmetric key. • KDC: server shares different secret key with each registered user (many users). • Alice, Bob know own their symmetric keys, KA-KDC and KB-KDC , for communicating with KDC. KDC

8. Key Distribution Centers (KDCs) Q: How does KDC allow Bob, Alice to determine shared symmetric secret key to communicate with each other? KDC generates R1 KA-KDC(A,B) KA-KDC(R1, KB-KDC(A,R1) ) Alice knows R1 Bob knows to use R1 to communicate with Alice KB-KDC(A,R1) Alice and Bob communicate: using R1 as session key for shared symmetric encryption

9. Key Distribution Centers (KDCs) Problems: • How are the keys shared with the KDC originally agreed upon and distributed? • Most approaches assume some form of manual key generation and distribution with the KDC. • The KDC is a critical, centralized part of network infrastructure. • This makes the KDC subject to interruption attacks to disrupt the general security of the network. • How does this approach scale? • A single KDC can not service all users of the Internet! • To scale, we require a collection of KDCs, that work together for key distribution.

10. What is authentication? • Positive verification of identity (man or machine) • Verification of a person’s claimed identity • Who are you? Prove it. • 3 Categories: • What you know • What you have • Who you are

11. What you know • Password • Pass phrase • PIN

12. What you have • Digital authentication • physical devices to aid authentication • Common examples: • eToken • smart cards • RFID- Radio Frequency Identification-(Integrated circuit(s) with an antenna that can respond to an RF signal with identity information)

13. Who you are • Physical Biometrics • Behavioral Biometrics

14. Physical Biometrics • Smell • Thermal Face • Nail Bed • DNA • Fingerprint • Iris • Ear Shape • Retina

15. Behavioral Biometrics • Signature • Voice • Keystroke • Gait

16. Review: Three Categories • What you know • Password • PIN • What you have • e-Token • RFID • Who you are • Biometrics

17. Motivation • Real-world considerations: • What you know and what you have • Can be stolen or forgotten • Susceptible to replay attacks • Who you are • Unique biometrics that hinder replay attacks and imposters

18. Three approaches to security • Rely on each individual client workstation to assure the identity of its users and rely on each server to enforce a security policy based on user identification (ID). • Require that client systems authenticate themselves to servers, but trust the client system concerning the identity of its users. • Require the user to prove identity for each service invoked. Also require that servers prove their identity to clients.

19. In small, closed environment, the first or perhaps the second strategy may suffice. • But in a more open environment. The third approach is needed. • The third approach is supported by Kerberos.

20. Requirements for Kerberos • Secure: A network eavesdropper should not be able to obtain the necessary information to impersonate a user. • Reliable: Kerberos should be highly reliable and should employ a distributed server architecture, with one system able to back up another. • Transparent • Scalable

21. Kerberos: • Developed in 1988 at MIT as part of Project Athena. • Athena was started in 1983 with the goal to provide campus-wide access to networked computing services. • Security problems (eavesdropping, forging identities, and so on) made it clear that a security solution was needed; Kerberos was the solution, based on Needham and Schroeder’s secret key protocol, with DES to handle encryption and decryption. • Since then, Kerberos has been used to provide secure access for various networked file systems and computing environments. • There are two commonly available versions of Kerberos, version 4 and version 5.

22. Kerberos: A KDC in Practice • At the heart of Kerberos is its own version of a Key Distribution Centre. • Each Kerberos KDC is responsible for what is called a realm, the set of systems, servers and users the KDC knows about. • In Kerberos version 5, facilities are provided to allow for multiple KDCs (in the same or different realms) to work together for authentication. • Each KDC is logically comprised of two services: • Authentication Service (AS): authenticates user clients and provides access to the TGS, below. • Ticket Granting Service (TGS): provides tickets and session keys to allow users to access particular services within the Kerberos realm.

23. AS TGS Kerberos KDC Server Client

24. AS TGS Kerberos KDC Server id. Authenticator TGT SK SK (ticket) Server Client

25. AS TGS Kerberos KDC Server SK Client Authenticator

26. Kerberos: Keys and Tickets • All communication in Kerberos is protected through symmetric key cryptography. • Each client (user) and server in Kerberos has a secret key known only by the individual and the Kerberos Authentication Service. (To facilitate the process, users have passwords that are transformed to their secret key when needed.) • For communication between everything else, session keys are used that generated by the Authentication Service or the Ticket Granting Service. • Tickets are tokens issued to clients to present to a particular server to verify that the client was recently authenticated by Kerberos. • Each ticket contains an expiry time and a session key for use by the client and the particular server. • There are two kinds of tickets: ticket-granting tickets (TGTs) for talking with the Ticket Granting Service and service tickets (STKs) for talking with individual servers.

27. Simple shared-secret based cryptographic authentication

28. Add mutual authentication

29. Problems with this scheme • Poor scaling properties • Generalizing the model for m users and n services, requires a priori distribution of m x n shared keys • Possible improvement: • Use trusted 3rd party, with which each user and service shares a secret key: m + n keys • Also has important security advantages

30. Mediated Authentication • A trusted third party mediates the authentication process • Called the Key Distribution Center (KDC) • Each user and service shares a secret key with the KDC • KDC generates a session key, and securely distributes it to communicating parties • Communicating parties prove to each other that they know the session key

32. Mediated Authentication

33. Mediated Authentication

35. The Kerberos Protocol • Suppose a client C wants to communicate with a server S in a Kerberos version 5 realm. Step 1: • The first step is for the client to authenticate itself with the Kerberos Authentication Service and request a Ticket Granting Ticket. • This requests a ticket for client (C) for the Ticket Granting Service (TGS), with N1 as a timestamp nonce. C AS C, KC-AS(TGS, N1)

36. The Kerberos Protocol Step 2: • When the Authentication Service receives the request, it decrypts the request and verifies the client’s identity. It then generates a session key for the client and Ticket Granting Service to use, as well as a ticket. It sends back:whereTGT = (C, TGS, T1, L1, KC-TGS)T1, L1 are the ticket’s timestamp and lifespan • Since this is encrypted with C’s secret key, only the client can make use of it, and only the Authentication Service could have sent it. C AS KC-AS(KC-TGS, KAS-TGS(TGT),N1)

37. The Kerberos Protocol Step 3: • With the client authenticated, it decrypts the response to get a session key for the Ticket Granting Service and a ticket-granting ticket. • When the client needs to contact the server S, it creates a fresh authenticator (AUTH) and requests a ticket from the Ticket Granting Service:whereAUTH=(C, ADc, N3) C TGS KC-TGS(AUTH), KAS-TGS(TGT), S, N2

38. The Kerberos Protocol Step 4: • The Ticket Granting Service decrypts the ticket-granting ticket and obtains the session key within it. • The service decrypts the authenticator and compares client identifiers in the authenticator and ticket. • The service generates a new session key for the client and server, as well as a service ticket, and sends:whereSTK = (C, S, T2, L2, KC-S)T2, L2 are the ticket’s timestamp and lifespan • Since this is encrypted with the session key, only the client can make use of it, and only the Ticket Granting Service could have sent it. C TGS KC-TGS(KC-S, KS-AS(STK),N2)

39. The Kerberos Protocol Step 5: • The client decrypts the response from the Ticket Granting Service to get the session key for the server and a service ticket to use with it. • When the client needs to contact the server S, it creates a fresh authenticator (AUTH) and sends this, along with the service ticket, and its request R:whereAUTH=(C, N5) C S KC-S(AUTH), KS-AS(STK), R, N4

40. The Kerberos Protocol Step 6: • The server decrypts the service ticket and obtains the session key within it. • The server decrypts the authenticator and compares client identifiers in the authenticator and ticket. • The server executes request R and replies with answer A, and the nonce in the client’s request. • Since this is encrypted with the session key, only the client can make use of it, and only server could have sent it. The session key can be used for additional requests in this session, and then destroyed. C S KC-S(A, N4)

41. The Kerberos Protocol C AS TGS S C, KC-AS(TGS, N1) KC-AS(KC-TGS, KAS-TGS(TGT),N1) KC-TGS(AUTH), KAS-TGS(TGT), S, N2 KC-TGS(KC-S, KS-AS(STK),N2) KC-S(AUTH), KS-AS(STK), R, N4 KC-S(A, N4)

42. Kerberos: Wrap-Up • Through its ticket-granting capabilities, one can achieve scalability by having one KDC grant a ticket permitting a client to contact a KDC in another realm. • But, we still have issues of setting up secret keys in the first place, and the potential for interruption attacks on the KDC itself. • Furthermore, Kerberos depends on a good network time service to synchronize system times for accepting timestamps. • This makes the time service a good target for interruption attacks too!

43. Multiple Realms • KDCA & KDCB must have registered with each other • Chains longer than two KDCs not allowed (v.4) “Alice”, “KDCB” KDCA ticket to KDCB Alice “Alice”, “Bob” KDCB ticket to Bob Bob AP_REQ