Kerberos is a network authentication protocol for client-server applications based on cryptographic keys. It's used in Windows 2000, Windows XP and Windows Server 2003 and later systems. Because it's an open standard, it can also used by non-Windows systems.
Unlike password-based authentication systems, passwords are never sent over the network. Kerberos authenticates by verifying identities of users and servers within a trusted environment. As such, Kerberos is inaccessible for outsiders. Once authenticated, the user or client can access multiple services without needing to authenticate again for each service. Encrypted tickets are used instead of passwords.
Security aspects covered by Kerberos include authentication, access control, and key exchange.
What are some essential Kerberos terms that a beginner should know?
Here are some essential Kerberos terms:
- Principal: This is a unique identity. Because Kerberos supports mutual authentication, both users and network resources have principals.
- Realm: Called domain in Windows, this is a logical grouping of resources and identities.
- Ticket: Ticket is an encrypted block of data that authenticates the user. Because of tickets, we don't need to transmit clear passwords over the Kerberos infrastructure. Tickets come with a configurable time expiry.
jdoe@SALES.WIDGET.COMis a principal for user
jdoewithin the realm
SALES.WIDGET.COM. It's quite possible for users to have multiple principals in different realms with different access rights. Another example is users enter the system in one realm and access resources in other realms.
Could you give an overview of the Kerberos' authentication flow?
Central to Kerberos is the Key Distribution Center (KDC) that has a database of trusted principals, the Authentication Service (AS), and the Ticket-Granting Service (TGS).
When a user logs into a client machine, she supplies a password. To gain access to network services, Kerberos protocol is invoked to authenticate the user. However, network services don't do the authentication on their own. KDC (and its AS) is the trusted third party that does this. The user's principal, and not the password, is sent to the KDC. KDC checks this against its database, authenticates the user and sends back the Ticket-Granting Ticket (TGT). All this happens transparent to the user when she logs in or invokes the
When the client wants to access a service, it presents the TGT to the TGS, which generates service session key and a service ticket containing this key. Whenever client wants, it presents the service ticket to the service. The client and the service can now start communicating, with all communication encrypted with service session key.
What are the different tickets used in Kerberos?
Kerberos has essentially two tickets. One is issued by the AS during authentication. The other is issued by the TGS when a service is requested.
AS issues the Ticket Granting Ticket (TGT). TGT is a ticket to tell the TGS that the client has already been authenticated.
TGS issues the Service Ticket after validating the TGT. This enables the client to access a service. Service ticket contains client's IP address, timestamp, and the service session key.
Both tickets are encrypted. Although the client is in possession of these tickets, it can't read them. The TGT is meant for the TGS. The service ticket is meant for the service provider.
What are the different keys used in Kerberos?
The following keys are used in Kerberos:
- Principal Key: Based on the principal's password, this encrypts the TGT and the session key between client and AS.
- Session Key: This is generated by the KDC during authentication and sent to the client. This is used to encrypt communication between client and TGS. In particular, TGT, service ticket request, service ticket, and service session key are encrypted using this.
- Ticket Granting Service (TGS) Key: This encrypts the TGT. The TGS uses this key to decrypt the TGT. TGS then checks that TGT hasn't expired and generates the service ticket and service session key.
- Service Key: This encrypts the service ticket. It's available within the KDC and also with the service provider.
- Service Session Key: This is used to encrypt all communication between the client and the service. This is generated in the TGS.
What are the main advantages of using Kerberos?
Here are some advantages of Kerberos:
- Mutual Authentication: Client and server authenticate each other. This protects clients from connecting to a bogus server.
- Open Standard: It's based on RFC 4120. Non-Windows systems that implement this RFC can also use Kerberos.
- Delegation: Also called authentication forwarding, a service can access remote resources on behalf of the client using the client's identity.
- Smart Card Logon: Beyond password logon, two-factor authentication using a smart card and PIN is possible.
- Passwords & Keys: User passwords are never sent over communication links. Eavesdroppers can't get hold of passwords. Secret keys are sent only in encrypted form. There's support for both symmetric and asymmetric keys.
- Encrypted Sessions: Service session key shared between the client and a service can be used to encrypt all conversation pertaining to the service.
- Integrated Sessions: Once authenticated, client can access a service without having to re-authenticate, until the ticket expires.
- Renewable Sessions: After the first session, subsequent sessions are setup faster. Server authenticates the client immediately without involving the KDC.
What's the difference between Kerberos impersonation and delegation?
Clients are authorized to access certain services but the services themselves run in a different security context, such as on a different thread, process or machine. Services acquire client credentials (such as service tickets) and use these to obtain resources on behalf of the clients. In some sense, services therefore impersonate the clients they serve.
There are four impersonation levels: anonymous, identify, impersonation and delegation. If the service is on the same computer as the client process, it can impersonate the client to access network resources. If the service is on a remote computer, it can impersonate the client for accessing resources on the service's computer. With delegation, the service can impersonate the client even when accessing resources on another computer.
Let's assume that a user requests data via a web server but the data resides on a different database server. The web server delegates to the database server to obtain necessary data from the database. Within the security context of the database server, which accesses the database on the same machine, we can say that impersonation happens.
How is Kerberos related to GSSAPI?
Generic Security Service API (GSSAPI) is a standard interface, defined by RFC 2743, that provides a generic authentication and secure messaging interface. Multiple security mechanisms can be plugged in so long as they conform to GSSAPI. IETF has defined two mechanisms: Kerberos V5 via RFC 1964 and Simple Public Key Mechanism (SPKM) via RFC 2025.
GSSAPI is an abstraction that must be accompanied by a security mechanism. The advantage is that applications are not tied to a particular mechanism. Migration is possible, such as, from SPKM to Kerberos V5. In fact, an implementation might support multiple mechanisms and applications can choose the mechanism at runtime. However, both client and server must negotiate to use the same mechanism.
GSSAPI was designed with the following goals:
- Mechanism independence: Applications need not concern with the security mechanism such as the type of cryptographic keys used.
- Protocol environment independence: API is not tied to particular communications protocol.
- Protocol association independence: A single API implementation can be used by different application modules that possibly use different communications protocols.
What are some limitations of Kerberos?
Kerberos is only as secure as the passwords being used. Weak passwords make the system vulnerable to brute force attacks. During protocol use, encryption keys are stored in memory in unencrypted form. Kerberos can't do anything about compromised user endpoints, authentication servers or KDC. If the authentication server is down, new users can't login. Pass the Ticket attack involves getting access to a ticket, moving laterally within the network and gaining access to critical systems.
Kerberos has strict timing requirements. Usually Network Time Protocol (NTP) daemons are used for clock synchronization. NTP therefore becomes a dependency.
If each service requires a different host name, each must use its own keys. This complicates deployment of virtual hosting and clusters. Kerberos works in a trusted environment and therefore hard to use on the public Internet where untrusted or unknown clients may want to connect.
Kerberos has worked well within the enterprise but hasn't been adopted in the cloud. A Kerberos ticket contains an encrypted key that could be hacked. Cloud services prefer to use SAML 2.0, OAuth 2.0 or OpenID Connect. In fact, cloud services have been poor in adopting identity federation standards.
At the Usenex conference, the Kerberos v4 protocol is described for the first time. This makes Kerberos one of the oldest authentication protocols since many others come years later: SAML (2002), WS-Federation (2003), OAuth2 (2010) and OpenID Connect (2014). Versions 1-3 of the protocol remained internal to MIT.
Kerberos v4 is released. It uses DES for encryption. Due to export restrictions, Kerberos can't be used outside the U.S. An alternative implementation from Sweden called KTH-KRB is released years later for non-U.S. markets. However, v4 has limitations: weak DES encryption, misuse of PCBC mode of DES, ticket lifetime can't be longer than about 21 hours, delegation not supported.
Kerberos v5 is released and standardized by IETF as RFC 1510. It overcomes many limitations of v4. It uses ASN.1 syntax. It adds new modes for DES. AES encryption is supported. Ticket lifetimes are much longer. Delegation is supported. It allows for unkeyed checksums (CRC, MD5, SHA-1) and keyed checksums (HMAC with MD5 or SHA-1). This is also the year when Microsoft decides to adopt Kerberos in its products.
- Alexandrov, Oleg. 2018. "Weakness Within: Kerberos Delegation." CyberArk Software Ltd., May 30. Accessed 2019-07-14.
- Broeckelmann, Robert. 2018a. "Kerberos v5 Related Specs and RFCs." Medium, May 17. Accessed 2019-07-07.
- Broeckelmann, Robert. 2018b. "Kerberos and Windows Security: History." Medium, June 01. Accessed 2019-07-07.
- Carle. 2012. "Cryptographic Protocols for Encryption, Authentication and Key Establishment." Chapter 3 in Network Security, TU München. Accessed 2019-07-14.
- Carter, Robert G. 2019. "Kerberos: Strengths and Weaknesses." Duke University. Accessed 2019-07-07.
- Cheung, Karin, Carol Chow, Mike Li, Jesse Koontz, and Ben Self. 1999. "Project Athena: Success in Engineering Projects." 6.933 Final Project, MIT, Fall 1999. Accessed 2019-07-14.
- Cohen, Eran. 2019. "10 Things You Need to Know About Kerberos." Preempt, June 24. Accessed 2019-07-07.
- De Clercq, Jan. 2004. "Kerberos advantages." Computer Weekly, September 28. Accessed 2019-07-14.
- Deuby, Sean. 2013. "Kerberos Might Not Be Dead, but It's Not Feeling Well." ITPro Today, November 25. Accessed 2019-07-14.
- Echeverria, Joey, and Ben Spivey. 2015. "Kerberos." Chapter 4 in Hadoop Security, O'Reilly Media, July. Accessed 2019-07-07.
- Gittins, Laura. 2013. "What Are the Advantages of Kerberos Authentication?" It Still Works, March 18. Updated 2019-01-10. Accessed 2019-07-07.
- Harbar, Spencer. 2009. "Kerberos Part One." Software Development Network, via SlideShare, December 16. Accessed 2019-07-13.
- IBM. 2015. "The Kerberos mode." IBM Spectrum Scale 4.2.0, November. Accessed 2019-07-15.
- Kaushal, Lalit. 2010. "Authentication on XenApp & XenDesktop." Citrix Summit 2010, via SlidePlayer. Accessed 2019-07-14.
- Kerberos Help. 2019. "Kerberos Terminology." MIT. Accessed 2019-07-07.
- Linn, J. 2000. "Generic Security Service Application Program Interface." Version 2, Update 1, RFC 2743, January. Accessed 2019-07-07.
- MIT KIT. 2019. "History." Massachusetts Institute of Technology. Accessed 2019-07-07.
- MIT Kerberos Consortium. 2008. "The Role of Kerberos in Modern Information Systems." MIT Kerberos Consortium. Accessed 2019-07-07.
- MIT Kerberos Consortium. 2019. "Homepage." Accessed 2019-07-15.
- Microsoft Docs. 2012. "Impersonation." Resource Kits, Windows 2000 Server, July 18. Accessed 2019-07-14.
- Muehlfeld, Marc, Filip Hanzelka, Lucie Maňásková, Aneta Šteflová Petrová, Tomáš Čapek, and Ella Deon Ballard. 2019. "Using Kerberos." Chapter 11 in System-Level Authentication Guide, Red Hat Enterprise Linux 7, Red Hat, Revision 7.0-29, April 08. Accessed 2019-07-07.
- Neuman, C., T. Yu, S. Hartman, and K. Raeburn. 2005. "The Kerberos Network Authentication Service (V5)." RFC 4120, IETF, July. Accessed 2019-07-14.
- Oracle. 2014. "About Kerberos Authentication." Section 21.6 in Oracle® Linux, Administrator's Guide for Release 6, revision 1645, February 05. Accessed 2019-07-07.
- Oracle. 2018. "Single Sign-on Using Kerberos in Java." From Security Developer’s Guide, Java Platform, Standard Edition, Release 10, March. Accessed 2019-07-07.
- Wikipedia. 2019a. "Needham–Schroeder protocol." Wikipedia, March 05. Accessed 2019-07-15.
- Wikipedia. 2019b. "Kerberos (protocol)." Wikipedia, June 18. Accessed 2019-07-07.
- Wikipedia. 2019c. "Project Athena." Wikipedia, June 18. Accessed 2019-07-07.
- MIT Kerberos Consortium. 2008. "The Role of Kerberos in Modern Information Systems." MIT Kerberos Consortium. Accessed 2019-07-07.
- MIT. 2019. "Kerberos: The Network Authentication Protocol." v1.244, January 09. Accessed 2019-07-07.
- Weeraman, Dewni. 2018. "Kerberos: The Computer Network Authentication Protocol." Medium, May 27. Accessed 2019-07-07.
- Oracle. 2010. "Kerberos Service." Part VI in System Administration Guide: Security Services, Part No: 816-4557-19, September. Accessed 2019-07-07.