Kerberos: A Network Authentication Tool

1. Kerberos: A Network Authentication Tool Seth Orr University of Missouri – St. Louis CS 5780 System Administration

2. Overview • Introduction • History • Components • Protocol • Installation and Configuration • Strengths and Weaknesses • Conclusions • References

3. Introduction • Security • As we have already seen, the world is full of unscrupulous people, and we must protect vital data and services. • Many tools exist for system administrators that provide security. • But, as security increases, so does user burden. • System administrators need a tool that is tough and convenient.

4. Introduction • Kerberos provides toughness and convenience. • So what is Kerberos any way?

5. Introduction • RFC 1510 States: Kerberos provides a means of verifying the identities of principals, (e.g., a workstation user or a network server) on an open (unprotected) network. This is accomplished without relying on authentication by the host operating system, without basing trust on host addresses, without requiring physical security of all the hosts on the network, and under the assumption that packets traveling along the network can be read, modified, and inserted at will. Kerberos performs authentication under these conditions as a trusted third-party authentication service by using conventional cryptography, i.e., shared secret key.

6. Introduction • Jason Garman’s Keberos: The Definitive Guide defines Kerberos as a “secure, single-sign-on, trusted, third-party mutual authentication service.” • What does this mean exactly?

7. Introduction • Kerberos provides a way to authenticate clients to services to each other through a trusted third party. • Kerberos makes the assumption that the connection between a client and service is insecure. • Passwords are encrypted to prevent others from reading them. • Clients only have to authenticate once during a pre-defined lifetime.

8. History • Kerberos was designed and developed at MIT by Project Athena. • Currently, Kerberos is up to Version 5. • Version 4 being the first version to be released outside of MIT. • Kerberos has been adopted by several private companies as well as added to several operating systems.

9. History • Its creation was inspired by client-server model replacing time-sharing model. • Users could not be trusted.

10. Components • Principals • Realms • Key Distribution Centers (KDC’s) • Authentication Service • Ticket Granting Server • Tickets • Authenticators

11. Components • Principals • each entity, such as clients or application servers, is represented as a principal • coupled with a key • stored with their keys in a database on the Key Distribution Center or KDC • must be unique

12. Components • Realms • companies and organizations are composed of different departments, each with a different function • to make things less complex, system administrators represent each department with a realm • each realm has its own KDC(s)

13. Components • Key Distribution Centers (KDC’s) • composed of an Authentication Service and Ticket Granting Server • has a database that houses all principals and their keys for a given realm • at least one KDC per realm

14. Components • Authentication Service (AS) • piece of software that accepts requests from clients • creates TGT’s based on the information in the request (principal names for client and service) • also establishes the secret session key used for communication between clients and services

15. Components • Ticket Granting Server (TGS) • responsible for accepting Ticket Granting Tickets • verifies that the TGT’s are correct • returns application service tickets clients based on the TGT’s • its existence allows for convenience because clients only have to authenticate themselves once to the AS to get TGT’s, which are presented to the TGS

16. Components • Tickets • according to Garman, “Tickets serve two purposes: to confirm identity of the end participants and to establish a short-lived encryption key that both parties can share for secure communication (called the session key)” • contains valuable data used by clients or services in order to confirm that the authentication is real

17. Components • Tickets • includes data such as: requesting client’s principal name, the application service’s principal name, when the ticket expires, a list of valid IP addresses, and a secret session key shared between the client and the application service • can either be Ticket Granting Tickets (TGT’s) for the TGS or for application services

18. Components • Authenticators • consist of timestamps that are encrypted with the secret session key shared between the client and the application service • can only be used once • timestamp can’t exceed maximum time frame • used to prevent replay attacks

19. Components

20. Protocol • Since clients could possibly be trying to access certain critical and important data or service from network applications, they have to prove in some way their identity. • We need some protocol for doing this authentication. • The Kerberos Version 5 authentication protocol is fully detailed in RFC 1510.

21. Protocol

22. Protocol • What if a client wants to access a service in another realm? • Cross-Realm Authentication • two realms, A and B • A’s TGS principal’s name and key are in B’s KDC principal database • B’s TGS principal’s name and key are in A’s KDC principal database • direct trust • hierarchical trust

23. Installation and Configuration • MIT • software available • http://web.mit.edu/kerberos/www/krb5-1.3/ • installation and configuration guides • http://web.mit.edu/kerberos/www/krb5-1.3/krb5-1.3.5/doc/krb5-install.html • http://web.mit.edu/kerberos/www/krb5-1.3/krb5-1.3.5/doc/krb5-user.html • http://web.mit.edu/kerberos/www/krb5-1.3/krb5-1.3.5/doc/krb5-admin.html • http://web.mit.edu/kerberos/www/krb5-1.3/krb5-1.3.5/doc/krb425.html • Heimdal • software available • http://www.pdc.kth.se/heimdal/ • installation and configuration guide • http://www.pdc.kth.se/heimdal/heimdal.html

24. Installation and Configuration • Windows • overview and guide • http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/kerberos.mspx • Shishi • software available • http://josefsson.org/shishi/

25. Installation and Configuration • Other guides • a resource with advice on how to “Kerberize” your site • http://www.ornl.gov/~jar/HowToKerb.html • a very good overview on Kerberos and its installation and configuration • http://www.ms.washington.edu/Docs/Kerberos/krb5-server-1.2.7/install.html • FAQ and information on configuration files • http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html

26. Strengths • Passwords are never sent across the network unencrypted. This prevents those unscrupulous people from being able to read the most important data sent over the network. • Clients and applications services mutually authenticate. Mutual authentication allows for both ends to know that they truly know whom they are communicating with. • Tickets have a limited lifetime, so if they are stolen, unauthorized use is limited to the time frame that the ticket is valid.

27. Strengths 4. Authentication through the AS only has to happen once. This makes the security of Kerberos more convenient. 5. Shared secret keys between clients and services are more efficient than public-keys. 6. Many implementations of Keberos have a large support base and have been put through serious testing. 7. Authenticators, created by clients, can only be used once. This feature prevents the use of stolen authenticators.

28. Weaknesses • Kerberos only provides authentication for clients and services. • Kerberos 4 uses DES, which has been shown to be vulnerable to brute-force-attacks with little computing power. • The principal-key database on the KDC has to be hardened or else bad things can happen. • Like any security tool, it is also vulnerable to users making poor password choices.

29. Conclusions • Organizations have networks based on the client-server model, but clients and servers never meet. • How do we prove identities then? • Must have some way of authentication to enable security. • However, an increase in security increases user burden.

30. Conclusions • Kerberos provides a means of authentication coupled with convenience over an unprotected network. • Kerberos never allows passwords to be sent unencrypted. • Initially developed at MIT, Kerberos is available from many sources and has a wide support base and documentation.

31. References • Bryant, Bill, and Theodore Ts’o. Designing an Authentication System: a Dialogue in Four Scenes. February 1997. Massachusetts Institute of Technology. 1 November 2004 <http://web.mit.edu/kerberos/www/dialogue.html>. • Garman, Jason. Kerberos: The Definitive Guide. Sebastopol, CA: O’Reilly, 2003. • “Kerberos: Advantages and Weaknesses.” Duke University. 20 November 2004. < http://www.oit.duke.edu/~rob/kerberos/kerbasnds.html >. • Kohl, J, and C. Neuman. The Kerberos Network Authentication Service (V5). September 1993. Internet Engineering Task Force. 1 November 2004 <http://www.ietf.org/rfc/rfc1510.txt>. • Naval Research Laboratory, Computational Meta-Facility. 8 August 2000. FrequentlyAsked Questions about Kerberos. 15 November 2004 <http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html>. • Neuman, B. Clifford, and Theodore Ts’o. Kerberos: An Authentication Service for Computer Networks. September 1994. Information Sciences Institute, USC. 15 November 2004 <http://gost.isi.edu/publications/kerberos-neuman-tso.html>. • Tung, Brian. The Moron’s Guide to Kerberos, Version 1.2.2. 19 December 1996. Information Sciences Institute, USC. 11 November 2004 <http://www.isi.edu/gost/brian/security/kerberos.html>.