Overview of Kerberos

1. Overview of Kerberos Chad Thoenen Scott Redding (Project Leader) Jim Luo University of TulsaDepartment of Mathematical & Computer SciencesCS 5493/7493 Secure System Administration & CertificationDr. Mauricio Papa University of Tulsa - Center for Information Security

2. Presentation Layout • Chad Thoenen • Background Information, why you might use Kerberos, and Design approaches • Scott Redding • Will present an overview of how the Kerberos protocol work • Jim Lou • Will cover the Guide to Windows 2000 Kerberos Settings University of Tulsa - Center for Information Security

3. Background Information • What is Kerberos? • Kerberos is a network authentication protocol. • It was designed to provide strong authentication for client/server applications by using secret-key cryptography. • Who developed Kerberos ? • The Massachusetts Institute of Technology (MIT) developed Kerberos in the 1980s as part of the Project Athena Network. The Athena Project attempted to discover how to design, implement, and manage distributed computing environments. University of Tulsa - Center for Information Security

4. Background Information continued … • Why is Kerberos needed? • Most computer systems use some form of password protection scheme to authenticate users using userids and passwords. • Anyone who happens to know the password can claim to be that user. • So, with that said, it is important to prevent people from listening in on the conversation between the computer and the user's workstation or terminal. • In a local-area network, several computers can share the same network, and any computer on that network can listen in on the others network traffic. • With the advent of network monitoring packages, it is relatively easy for a user to set up a program to listen in on a network for any and all passwords being sent over the network. University of Tulsa - Center for Information Security

5. Background Information continued … • Note, The Electronic Communications Privacy Act of 1986 makes stealing data a Federal punishable crime. • In MIT circumstance, since Athena and MITnet use a workstation-based model of computation, with most operations taking place on a single-user workstation with occasional requests (for files, etc.) going to other "server" machines, Athena needed to set up some way of allowing users to prove their identity to such server machines. University of Tulsa - Center for Information Security

6. Key Terms • serviceA program or set of programs running on a computer which is accessible over the network. The service would like to know with certainty that the workstation to which it is providing the service is really being used by the user who claims to be logged in on the workstation. • principalAn entity that can both prove its identity and verify the identities of other principals who wish to communicate with it; each user and each service registered with Kerberos is thus a principal. University of Tulsa - Center for Information Security

7. Key Terms continue … • ticketA block of data which, when given to a user, enables him to prove his identity to a service. In the Athena environment tickets are stored in files in the /tmp directory, and are automatically erased on log-out. They contain information which must be considered private to the user, and thus the file should be kept at protection mode 700. As they contain a time stamp, they cease to be valid after eight hours. One ticket is needed for each service; tickets are used to build authenticators, which are sent over the network to the service. University of Tulsa - Center for Information Security

8. Key Terms continue … • authenticatorA block of data which a user's workstation sends over the network to a specific service to prove that the workstation really is in use by that user. An authenticator expires after five minutes. One authenticator is typically built per session of use of a service; once the service decodes the authenticator, it generally permits the user to operate for as long as she wants. This behavior is not in any way mandated by the Kerberos suite of programs and libraries (it is just a detail of the implementation), but it is convenient and considered secure enough for the Athena environment. University of Tulsa - Center for Information Security

9. Designing an Authentication System • Designing and Authentication System: a Dialogue in Four Seasons • http://web.mit.edu/kerberos/www/dialogue.html • The dialogue was written in 1988 to help readers understand the fundamental reasons for why the Kerberos V4 protocol was the way it was. • Still applicable for Kerberos V5 protocol, with only two changes from the description of the “Kerberos” protocol in the dialogue. University of Tulsa - Center for Information Security

10. Designing an Authentication System continued … • Abstract • This dialogue provides a fictitious account of the design of an open-network authentication system called "Charon." As the dialogue progresses, the characters Athena and Euripides discover the problems of security inherent in an open network environment. Each problem must be addressed in the design of Charon, and the design evolves accordingly. Athena and Euripides don't complete their work until the dialogue's close. • When they finish designing the system, Athena changes the system's name to "Kerberos," the name, coincidentally enough, of the authentication system that was designed and implemented at MIT's Project Athena. The dialogue's "Kerberos" system bears a striking resemblance to the system described in Kerberos: An Authentication Service for Open Network Systems presented at the Winter USENIX at Dallas, Texas in 1988. University of Tulsa - Center for Information Security

11. Designing an Authentication System continued … • Characters • Athena • an up and coming system developer. • Euripides • a seasoned developer and resident crank. University of Tulsa - Center for Information Security

12. Designing an Authentication System continued … • Page 1 - 17 • Scene I • A cubicle area. Athena and Euripides are working at neighboring terminals. • Athena: Hey Rip, this timesharing system is a drag. I can't get any work done because everyone else is logged in. • Euripides: Don't complain to me. I only work here. • Athena: You know what we need? We need to give everyone their own workstation so they don't have to worry about sharing computer cycles. And we'll use a network to connect all the workstations so folks can communicate with one another. • Euripides: Fine. So what do we need, about a thousand workstations? • Athena: More or less. • Euripides: Have you seen the size of a typical workstation's disk drive? There isn't enough room for all the software that you have on a timesharing machine. • Athena: I figured that out already. We can keep copies of the system software on various server machines. When you login to a workstation, the workstation accesses the system software by making a network connection with one of the servers. This setup lets a whole bunch of workstations use the same copy of the system software, and it makes software updates convenient. You don't have to trundle around to each workstation. Just modify the system software servers. • Euripides: All right. What are you going to do about personal files? With a timesharing system I can login and get to my files from any terminal that is connected to the system. Will I be able to walk up to any workstation and automatically get to my files? Or do I have to make like a PC user and keep my files on diskette? I hope not. • Athena: I think we can use other machines to provide personal file storage. You can login to any workstation and get to your files. • Euripides: What about printing? Does every workstation have its own printer? Whose money are you spending anyway? And what about electronic mail? How are you going to distribute mail to all these workstations? University of Tulsa - Center for Information Security

13. Designing an Authentication System continued … • Scene I • Main Concept • Timesharing systems can prevent user from getting work accomplished when everyone is logged in. • They need to get everyone their own workstations so they don’t have to share computer cycles. • Problems surrounding Main Concept • Individual workstations do not have enough disk space for the system software stored on the timesharing machine • Is everyone going to need a printer? • How is mail going to be routed to the users? • In an open network environment, machines that provide services must be able to confirm the identities of people who request service. University of Tulsa - Center for Information Security

14. Designing an Authentication System continued … • Scene II • Resolution to Problem in Scene I • Quick fix is to require a password to access a service. • Each user knows her or his password, each service program knows its password, and there's an AUTHENTICATION SERVICE (Charon) that knows ALL passwords--each user's password, and each service's password. The authentication service stores the passwords in a single, centralized database. • Main Concept • Charon produces a ticket instead of a password. • Issues with decrypting the ticket cause the two to add more to the ticket. You can make a workstation think you are someone who you are not, so they also added the workstation ip address to the ticket as well. • {username:ws_address:servicename} University of Tulsa - Center for Information Security

15. Designing an Authentication System continued … • Scene II continue … • Main Concept continue … • Tickets will be need to be reusable. • Problems surrounding Main Concept • Users only have to enter their passwords once, at the beginning of their workstation sessions. This requirement implies that you shouldn't have to enter your password every time you need a new service ticket. • The second requirement: passwords should not be sent over the network in clear text. University of Tulsa - Center for Information Security

16. Designing an Authentication System continued … • Scene III • Resolution to Problem in Scene II • (Athena) I've met this requirement by inventing a new network service. It's called the "ticket-granting" service, a service that issues Charon tickets to users who have already proven their identity to Charon. You can use this ticket-granting service if you have a ticket for it, a ticket-granting ticket. • Main Concept • Charon uses the username to look up your password. Next Charon builds a packet of data that contains the ticket-granting ticket. Before it sends you the packet, Charon uses your password to encrypt the packet's contents. • Your workstation receives the ticket packet. You enter your password. kinit attempts to decrypt the ticket with the password you entered. If kinit succeeds, you have successfully authenticated yourself to Charon. You now possess a ticket-granting ticket, and that ticket can get you the other tickets you require. University of Tulsa - Center for Information Security

17. Designing an Authentication System continued … • Scene III continue … • Main Concept continue … • Expiration timeframes for tickets and a ticket-destroying program. • Problems surrounding Main Concept • At first, tickets had no expiration date. Then they decided on tickets expiring after eight hours. • If a user logs out before the eight hour window expires, for example having six hours left, a user would have time if they had stolen your tickets to REPLAY your tickets and gain access to your data. University of Tulsa - Center for Information Security

18. Designing an Authentication System continued … • Scene IV • The final act … • Scene four is the final round and they outline the process in detail of how Kerberos works. • I will stop here as Scott will talk about the details of how the protocol works. • This dialog was to give you some idea of how the protocol was originally designed. University of Tulsa - Center for Information Security

19. Players • Client – Also called the principal, it’s the Workstation user • Server – Who the Client wants to communicate with • Authenticator – Facilitator for secure communication, the Ticket Granting Server. Can also be the Key Distribution Center (KDC) • KDC – Server where key database is kept University of Tulsa - Center for Information Security

20. Terms • Ticket – Similar to a carnival ticket, you must have one to play the game • Unforgeable, nonreplayable, authenticated object • Contains • Client ID • Requested service • Access rights for the service • Timestamp • Symmetric cryptographic session key • Ticket Granting Ticket – Allows the Client to request tickets from the Ticket Granting Server University of Tulsa - Center for Information Security

21. Process • Authentication Service Exchange • Initial exchange between Client and Authenticator • They already share a secret key • Client obtains ticket enabling Client to establish session with a Server • Server typically set up for session is the Ticket Granting Server University of Tulsa - Center for Information Security

22. Process • Ticket Granting Service Exchange • Doesn’t use the Client’s secret key, uses TGT • Used to obtain ticket to establish session with Server University of Tulsa - Center for Information Security

23. Process • Client - Server Authentication Exchange • Between Client and target Server • Authenticates Client to Server • Authenticates Server to Client • Both share symmetric key that can be used for encrypted communication University of Tulsa - Center for Information Security

24. Next Slide Requires Power Point 2002 in order to View animation. University of Tulsa - Center for Information Security

25. Authenticator (KDC) Client ID Timestamp1 Client Request for Credentials Timestamp2 Server Timestamp2, ID University of Tulsa - Center for Information Security

26. It’s not really that simple • Initial exchange is request for credentials to talk with the Ticket Granting Service (TGS) • Similar process to that just described gets Client a Ticket Granting Ticket (TGT) • TGT is used from this point forward to acquire tickets from the TGS. • Why? Single sign-on. University of Tulsa - Center for Information Security

27. Challenges • System Administration • KDC – holds “keys to the kingdom” • Physical security • Network connectivity • Software Integration • “r” service program replacements • Kerberization of programs • User Education University of Tulsa - Center for Information Security

28. Advantages • Good protection • Relatively inexpensive technology • Passwords are not communicated over network (not even encrypted passwords) • Procedures exist for use across multiple domains called realms “Cross-Realm Authentication” • Built-in support in some operating systems University of Tulsa - Center for Information Security

29. Disadvantages • Trusted, high availability servers required • Time stamps require secure synchronized clocks • Scaling to large user populations is difficult • Password, ticket security required on Client system • Applications need to be “kerberized” University of Tulsa - Center for Information Security

30. Windows 2000 Kerberos University of Tulsa - Center for Information Security

31. Authentication in Windows 2000 • Kerberos Version 5 • The default for Windows 2000 • Protocol of choice when there is a choice • Windows NT LAN Manager (NTLM) • Retained in Windows 2000 for backward compatibility • The default authentication protocol for Windows NT 4.0 • Machines running Windows 3.1, Windows 98, and Windows NT in Windows 2000 domains • Windows 2000 machines authenticating through a Windows NT server • Stand alone Windows 2000 machines University of Tulsa - Center for Information Security

32. How It Works • The Kerberos Version 5 services are installed on each domain controller • A Kerberos client is installed on each Windows 2000 workstation and server. • Every domain controller acts as a Key Distribution Center (KDC). Clients locate KDC’s through a DNS lookup. • The nearest available domain controller serves as the preferred KDC for that user during the user's logon session. University of Tulsa - Center for Information Security

33. How It Works • The user on a client system, using a password or a smart card, authenticates to the Key Distribution Center (KDC). • The KDC issues a special ticket-granting ticket (TGT) to the client. • The client uses TGT to access the ticket-granting service (TGS). The TGS issues service ticket to the client. • The client presents this service ticket to the requested network service. The service ticket provides mutual authentication University of Tulsa - Center for Information Security

34. Kerberos Advantages • More efficient authentication to servers • Mutual authentication • Delegated authentication • Simplified trust management • Interoperability • Invisible to users University of Tulsa - Center for Information Security

35. Kerberos Policy • Kerberos policy is defined at the domain level and implemented by the domain's Key Distribution Center (KDC). • Kerberos policy is stored in Active Directory as a subset of the attributes of a domain security policy. • Kerberos is normally an automatic process and you are not required to set it up. There are very few policy choices that can be applied to Kerberos. University of Tulsa - Center for Information Security

36. Kerberos Policy • “The primary thing to remember about configuring Kerberos is that the default is good… Unless there is some specific reason to change one of the parameters, you should leave the parameters alone” • Microsoft • NSA agrees. University of Tulsa - Center for Information Security

37. Kerberos Policy • Enforce User Logon Restrictions • Default Value: Enabled. NSA Recommendation: Enabled • Maximum Lifetime That a User Ticket Can Be Renewed • Default: 7 days. NSA: 7 Days • Maximum Service Ticket Lifetime • Default: 10 hours. NSA Recommendation : 10 hours • Maximum Tolerance for Synchronization of Computer Clocks • Default value: 5 minutes. NSA Recommendation: 5 minutes • Maximum User Ticket Lifetime – • Default value: 10 hours. NSA Recommendation: 10 hours University of Tulsa - Center for Information Security

38. Account Policy • Smart Card required for interactive login • Default Value: Disabled NSA Recommendation: Disabled • Account trusted for delegation • Default Value: Disabled NSA Recommendation: Disabled • Account is sensitive and cannot be delegated • Default Value: Disabled NSA Recommendation: Disabled • Use DES Encryption for this account • Default Value: Disabled NSA Recommendation: Disabled • Does not require Kerberos pre-authentication • Default Value: Disabled NSA Recommendation: Disabled University of Tulsa - Center for Information Security

39. Kerberos Interoperability • The Microsoft Windows 2000 operating system implementation of Kerberos conforms to the MIT Kerberos version 5 reference implementation for interoperability • It can integrate with Kerberos services in heterogeneous networks running different operating systems. University of Tulsa - Center for Information Security

40. Kerberos Interoperability • A Windows 2000 Server domain controller can serve as the Kerberos Key Distribution Center (KDC) server for MIT Kerberos-based client and host systems • Windows 2000 Professional clients can be configured to use a Kerberos realm, with single sign-on to the Kerberos realm and the local Windows 2000 Professional-based client account University of Tulsa - Center for Information Security

41. Kerberos Interoperability • The Windows 2000 Kerberos Security Support Provider (SSP) implements the General Security Service Application Program Interface (GSS API) Kerberos Mechanism Token formats defined in RFC 1964. Windows 2000 does not provide the GSS API; instead, the Kerberos support is available to Microsoft Win32 API-based applications using the SSPI APIs implemented by the Kerberos SSP. Client applications on UNIX using GSS API can obtain session tickets to services on Windows 2000, and can complete mutual authentication, message integrity, and confidentiality University of Tulsa - Center for Information Security

42. Interoperability Configuration • Interoperability with Kerberos services requires minor configuration changes from the default installation. • For example, a Windows 2000 workstation that uses a Kerberos realm must be configured to: • Locate the Kerberos realm • Locate available KDC servers • Locate available Kerberos change password servers. University of Tulsa - Center for Information Security

43. Kerberos Interoperability Tools • Ksetup – Configures Kerberos realms, KDCs, and Kpasswd servers. • Ktpass – Sets the password, account name mappings, and keytab generation for Kerberos services that use the Windows 2000 Kerberos KDC. • Gssclient – tests RFC 1964 interoperability • Gssserver – tests RFC 1964 interoperability • Klist – examines the Kerberos credential cache. University of Tulsa - Center for Information Security

44. Interoperability Limitations • Only DES-CBC-MD5 and DES-CBC-CRC encryption types are available for MIT Kerberos interoperability. • Hierarchical realm support for cross-platform trust between the Windows 2000 and MIT Kerberos realms is not included; however, transitive trust is supported between Windows 2000 domains in the domain tree. • The KDC does not support post-dated tickets. • Any upgraded user accounts and the administrator account in a new domain must have the password changed before non-Windows Kerberos clients can use them. University of Tulsa - Center for Information Security

45. Kerberos in Linux University of Tulsa - Center for Information Security

46. A Few Words in Linux • No simple way of migrating passwords from Unix databases to Kerberos databases • Only partly compatible with Pluggable Authorization Modules (PAM’s) • Applications have to be source modified to use Kerberos to authenticate • Adoption of Kerberos is all or nothing. University of Tulsa - Center for Information Security

47. QuEsTiOnS? University of Tulsa - Center for Information Security

48. References • http://web.mit.edu/is/help/kerberos/whatis.html • http://web.mit.edu/kerberos/www/dialogue.html • http://www.ntsecurity.net/Articles/Index.cfm?ArticleID=18 University of Tulsa - Center for Information Security