What Is Kerberos?

What is it?

1. 1. Kerberos is an authentication protocol enabling systems and users to prove their identity through a trusted third-party. The protocol was initially developed at the Massachusetts Institute of Technology (MIT) as part of a larger project called Project Athena. Project Athena was a joint initiative of MIT, Digital Equipment Corporation, and IBM to build a distributed computing environment for educational use.  
2. 2. The protocol centers around tickets. Tickets are issued by the trusted third-party and utilize symmetric encryption (the key known only to the trusted third-party) to establish their trust. As we’ll explain later, certain user passwords are also used to encrypt and sign specific tickets. However, the root of the protocol’s security is the key used by the trusted third-party. 
3. 3. The Kerberos implementation found within Microsoft Active Directory is based off of the Kerberos Network Authentication Service (V5), which is detailed in RFC 4120. Microsoft expanded upon the base protocol specification adding a number of extensions to the protocol (MS-KILE) to implement behaviors and features specific to Active Directory and the Windows operating system. 
4. 4. Kerberos authentication is currently the default authorization technology used by Microsoft Windows, and implementations of Kerberos exist in Apple OS, FreeBSD, UNIX, and Linux.
5. 5. Microsoft introduced their version of Kerberos in Windows2000. It has also become a standard for websites and Single-Sign-On implementations across platforms. The Kerberos Consortium maintains Kerberos as an open-source project.
6. 6. Kerberos is a vast improvement on previous authorization technologies. The strong cryptography and third-party ticket authorization make it much more difficult for cybercriminals to infiltrate your network.
7. 7. It is not totally without flaws, and in order to defend against those flaws, you need to first understand them.
8. 8. Kerberos has made the internet and its denizens more secure, and enables users to do more work on the Internet and in the office without compromising safety.
9. 9. Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography.
10. 10. A free implementation of this protocol is available from the Massachusetts Institute of Technology. Kerberos is available in many commercial products as well.
11. 11. The Internet is an insecure place. Many of the protocols used in the Internet do not provide any security. Tools to “sniff” passwords off of the network are in common use by malicious hackers.
12. 12. Thus, applications which send an unencrypted password over the network are extremely vulnerable. Worse yet, other client/server applications rely on the client program to be “honest” about the identity of the user who is using it.
13. 13. Other applications rely on the client to restrict its activities to those which it is allowed to do, with no other enforcement by the server.
14. 14. Some sites attempt to use firewalls to solve their network security problems. Unfortunately, firewalls assume that “the bad guys” are on the outside, which is often a very bad assumption. Most of the really damaging incidents of computer crime are carried out by insiders.
15. 15. Firewalls also have a significant disadvantage in that they restrict how your users can use the Internet. (After all, firewalls are simply a less extreme example of the dictum that there is nothing more secure than a computer which is not connected to the network — and powered off!) In many places, these restrictions are simply unrealistic and unacceptable.
16. 16. Kerberos was created by MIT as a solution to these network security problems. The Kerberos protocol uses strong cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection.
17. 17. After a client and server has used Kerberos to prove their identity, they can also encrypt all of their communications to assure privacy and data integrity as they go about their business.
18. 18. Kerberos is freely available from MIT, under copyright permissions very similar to those used for the BSD operating system and the X Window System.
19. 19. MIT provides Kerberos in source form so that anyone who wishes to use it may look over the code for themselves and assure themselves that the code is trustworthy.
20. 20. In addition, for those who prefer to rely on a professionally supported product, Kerberos is available as a product from many different vendors.
21. 21. Kerberos is a client-server authentication protocol that enables mutual authentication –  both the user and the server verify each other’s identity – over non-secure network connections. 
22. 22. The protocol is resistant to eavesdropping and replay attacks, and requires a trusted third party.
23. 23. The Kerberos protocol uses a symmetric key derived from the user password to securely exchange a session key for the client and server to use.
24. 24. A server component is known as a Ticket Granting Service (TGS) then issues a security token (AKA Ticket-Granting-Ticket TGT) that can be later used by the client to gain access to different services provided by a Service Server.

How Kerberos works?

So let’s see how this works. As I mentioned this includes following three entities,

Client: a user, a service of any software.

Server: where the kerberos protected resource/service is hosted

Key Distribution Center (KDC): The trusted third-party authentication service

kdc-navigate

The KDC includes following two servers:

• Authentication Server (AS) that performs the initial authentication and issues ticket-granting tickets (TGT) for users.
• Ticket-Granting Server (TGS) that issues service tickets that are based on the initial ticket-granting tickets (TGT).

key-client-navigate

1. 1. Client sends a request to Authentication Server (AS) with plaintext user ID and asks for server access on behalf of the user. This request is partially encrypted with a secret key which is the password of the client user.
2. 2. Authentication Server (AS) retrive the secret key (user’s password) from the user DB based on the user ID and uses his password as a key to decrypt the request. That is how the user is verified. Then the AS sends a Ticket-Granting Ticket (TGT) encrypted with another secret key which is shared between AS and Ticket-Granting Server (TGS).
3. 3. Clients send the encrypted TGT to the Ticket-Granting Server (TGS) requesting the access for the server.
4. 4. Ticket-Granting Server (TGS) decrypts the TGT with a shared secret key with AS and issues a kerberos token to the client which is encrypted with another shared secret key with TGS and server.
5. 5. Client sends a request to the server with the encrypted kerberos token.
6. 6. Then the server allows the access to the requested resources to the client for a certain period of time specified in the token.
7. 7. That’s how the basic kerberos flow works and it’s pretty straightforward. So all the communication steps involve shared secret keys which makes kerberos a very good example of symmetric key encryption!

How Does it Work?

Kerberos was originally named after Cerberus – the three headed dog, in Greek mythology, that guards the gates of the Hades – because of the three distinct actors in the protocol: 

• Client: The entity seeking to provide its identity. 
• Application Server (AP): The service that the client (or user) wants to access. 
• Key Distribution Center (KDC): The trusted third-party, which issues tickets. In Active Directory each domain controller acts as a KDC. The KDC provides two core services: Authentication Service (AS) which authenticates clients and issues them tickets, and the Ticket-Granting Service (TGS) which accepts authenticated clients and issues them tickets to access other resources. 

Kerberos Authentication Flow

TL;DR: A client requests a ticket for a user from the KDC using the user’s password to encrypt the request. If the KDC can decrypt the request with the user’s password it knows, it knows the client has supplied the correct password for the user. The KDC creates a ticket-granting ticket (TGT) for the user and encrypts the TGT with the user’s password and returns it to the client. If the client can decrypt the ticket with the password it has then it knows that the KDC is legitimate (this is a form of mutual authentication). 

A client requests a ticket for a service from the KDC by presenting its TGT and a ticket-granting service (TGS) request that includes the service principal name for the service it would like to access. The KDC creates a service ticket (TGS)which is encrypted with the service’s password hash, then encrypts the ticket and authenticator message with the shared ticket-granting service session key, and finally sends the TGS back to the client. 

A client requests access to an application server (service) by presenting the service ticket it obtained from the KDC to the application server, which decrypts the message using its own password hash. If it successfully decrypts the TGS, the application server grants access to the client.  

What follows is a more detailed step-by-step diagram and breakdown:

• 1. KRB_AS_REQ : Request TGT from Authentication Service (AS)  : The client’s request includes the user’s User Principal Name (UPN) and a timestamp. It is encrypted using the user’s password hash. 

• 2. KRB_AS_REP : TGT Received from Authentication Service  : The KDC uses the UPN to look up the client in its database and uses the user’s password hashto attempt to decrypt the message. 
• If the KDC successfully decrypts the TGT request and if the timestamp is within the KDC’s configured time skew, the authentication is successful. 
• A TGT and a TGS session key are sent back to the client. The TGS session key is used to encrypt subsequent requests. 

• 3. KRB_TGS_REQ : Present TGT and TGS request  : The client presents its TGT along with a request including the Service Principal Name (SPN) for the service it wants to access. 
• The TGS request is encrypted with the TGS session key. 

• 4. KRB_TGS_REP : Receive TGS from KDC  : The KDC validates the TGT, and if successful a TGS is generated. The TGS contains information about the requestor (like their SID and group memberships) and is encrypted with the service’s password hash. 
• The TGS and the service session key are encrypted with the TGS session key then sent back to the client. 

• 5. KRB_AP_REQ : Present TGS to Application Server for Authorization : The client sends the TGS which it received from the KDC to the application server along with an authenticator message which is encrypted with the service session key. 

• 6. KRB_AP_REP : Grant Client Access to the Service : The client receives the message and decrypts it with the service session key. 
• The Application Server extracts the Privilege Attribute Certificate (PAC) from the service ticket to verify its contents with a domain controller. 
• Validation of the ticket/PAC only happens when the Ticket Granting Ticket (TGT) is older than 20 minutes. 

Enhance Your Career with CCNA Training & Certifiation from Certified Experts

• Instructor-led Sessions
• Real-life Case Studies
• Assignments

Explore Curriculum

Important Factors

There are a handful of factors that influence how Kerberos operates, and can be sources of problems if not sufficiently provided for. 

• Replication between domain controllers
  If multiple domain controllers (i.e. multiple KDCs) are deployed, then replication must be enabled and converge in a timely manner. Should replication fail or convergence be delayed, authentication failures are possible when a user changes their password. 
   
• Clients and KDCs must use NETBIOS and DNS name resolution
  Kerberos Service Principal Names normally include NETBIOS and DNS addresses, which means both the KDC and Client must be able to resolve those names the same way. In certain situations, IP addresses may also be used in Service Principal Names.
   
• Clients and KDCs must have their clocks synchronized
  Accurate measurement of time is important in Kerberos to prevent replay attacks. Kerberos supports a configurable time skew (default 5 minutes) outside of which authentication will fail. 

• Clients and KDCs must be able to communicate on the network
  Kerberos traffic occurs on TCP and UDP port 88, which must be accessible from all clients to at least one KDC (domain controller).
   
• Clients, Users, and Services must have unique names
  Duplicate names for computers, users, or Service Principal Names can cause Kerberos unexpected Kerberos authentication failures. 

Where is Kerberos Used?

Microsoft’s Active Directory is the most widely consumed Kerberos implementation. Support for Kerberos is found in almost every operating system – from Apple OSX/iOS to many UNIX and Linux distributions. While Microsoft implements a heavily extended version of the Kerberos protocol, there are also software packages that implement the core specification that can be used to provide secured authentication in several contexts. 

Kerberos vs LDAP

When reading about Kerberos, you’ll frequently see mentions of LDAP. Kerberos and LDAP are commonly joined together (including in Active Directory) to provide a centralized user directory (LDAP) and authentication (Kerberos) services. 

LDAP, the Lightweight Directory Access Protocol, stores information about users, groups, and other objects (like computers) in a central location. It can also provide for simple authentication, however these native protocols, unlike Kerberos, generally require the user’s secret (i.e. password) to be transmitted over the network. Each resource the user wants to access must handle the user’s password and separately authenticate the user to the directory. 

Unlike LDAP, Kerberos provides for single sign-on functionality. Once a user has authenticated to the KDC, no other service (like an intranet site or file share) needs the user’s password. The KDC – that trusted third-party – is responsible for issuing tickets that each service trusts. The combination of LDAP and Kerberos provides centralized user management and authentication, and in larger networks this provides substantial security benefits.  

How can I see my Kerberos Tickets?

If you’re curious, it is easy to see your Kerberos tickets in the wild. On a Microsoft Windows computer, you can use the klist.exe program to enumerate them. 

You can view the tickets issued to you on your computer by opening a command prompt or Powershell and running klist tickets. In the example below, you can see that Joe has a ticket for the CIFS service, which is file share access, to a server called fileserver1.

PS C:\Windows\system32> klist tickets

Current LogonId is 0:0xe67df

Cached Tickets: (4)

#0>     Client : Joe @ domain.local

        Server : cifs/fileserver1.domain.local/domain.local @ DOMAIN.LOCAL

        KerbTicket Encryption Type : AES-256-CTS-HMAC-SHA1-96

        Ticket Flags 0x60a10000 -> forwardable forwarded renewable pre_authent name_canonicalize

        Start Time : 7/10/2020 12:33:49 (local)

        End Time :   7/10/2020 22:32:13 (local)

        Renew Time : 7/17/2020 12:32:13 (local)

        Session Key Type : AES-256-CTS-HMAC-SHA1-96

        Cache Flags : 0x40 -> FAST

        Kdc Called : DC1.domain.local

Conclusion

Kerberos is a well-known and widely used authentication protocol that also lies at the heart of Microsoft’s Active Directory. Given this stature, it has become one of the protocols most targeted for abuse by adversaries of all shades. At Stealthbits, we’ve dedicated ourselves to helping enterprises protect themselves from and detect these attacks. If you’re interested in learning more about attacks on Active Directory and Kerberos, visit the Stealthbits Attack Catalog; or, learn about how our solutions can help you defend your network.