Kerberos Authentication Protocol
You have a project. You need to connect an application over an insecure network. How should you do it if you don’t want to put application security at risk? One of the solutions that is pretty popular in big organizations is a Kerberos authentication protocol.
Kerberos provides secure authentication to services over an insecure network. Passwords are never sent across the network, encryption keys are never directly exchanged, and the user and the application can authenticate one another.
Many organizations use Kerberos as the base for single sign-on.
Kerberos – Definition of the components
A Kerberos realm is a domain in which a Kerberos authentication server can authenticate a user to a service. You can have multiple realms and you can interconnect them. Within a realm, there are principals.
A principal is a unique identity that is either a user or a service (e.g. application).
A client is a process that accesses a service on behalf of a user. It’s possible to have multiple clients or users within one realm. Basically, these are users that want to access an application.
A service is a resource provided to a client. It can be a file server or an application that a user wants to access. It’s possible to have multiple services that clients can access.
The key distribution center (KDC), is the core of Kerberos, the KDC creates tickets and generates temporary session keys that allow a user to securely authenticate to a service. The KDC stores all the secret symmetric keys for users and services.
There are two servers within the KDC, the authentication server, and the ticket-granting server. The authentication server confirms that a known user is making an access request and creates Ticket-Granting Tickets (TGT). The ticket-granting server confirms that a user is making an access request to a known service and issues service tickets.
There’s a huge number of messages sent back and forth between the user, authentication server, ticket-granting server, and the service. At least two messages are sent at almost every step. Some messages are sent in plain text while some are encrypted with a symmetric key.
There are two important types of messages that are worth stressing out.
Authenticators are records, containing information that can be shown to have been recently generated using the session key known only to the client and the server. Authenticators allow the user to authenticate to the service and the service to authenticate to the user.
Tickets contain most of the information that needs to be passed. The client’s identities, Service IDs, session keys, timestamps, time to live, etc. All encrypted using a server’s secret key.
Kerberos KDC
Kerberos KDC and the communication between a user and a service
- First, the user sends an unencrypted message to the authentication server basically asking for permission to access some service.
- The authentication service validates that the request is coming from a known user and generates a ticket-granting ticket (TGT).
- The TGT is then sent back to the user, along with another message encrypted with the user’s secret key.
- The user decrypts the message with his or her secret key and then creates some new messages and sends them along with the TGT onto the ticket-granting service.
- The ticket-granting service decrypts the ticket-granting ticket, performs some validation, and generates a service ticket.
- The service ticket, along with another message, is sent back to the user.
- The user decrypts the message, creates an authenticator message, and sends the user authenticator and the service ticket to the service.
- The service does its own decryption, validation and creates its own final authenticator message.
- This final authenticator message is sent back to the user. All of these messages allow the user and the server to mutually authenticate each other and securely distribute a symmetric service session key, which allows the user and the service to communicate authentication information securely.
Secfense supports Kerberos Authentication
Supporting Kerberos Authentication is something that we have been working on lately. And we are happy to announce that the User Access Security Broker from Secfense now supports Kerberos Authentication as well.
The User Access Security Broker is the core product from Secfense that is meant to deliver any strong authentication method to any application. What differentiates Secfense broker is that strong authentication mechanisms can be added to any application without making any changes in the application code. In this way security admins in big organizations can take advantage of Secfense technology and deploy:
- SMS Authentication
- The Time-based One-time Password (TOTP) Authentication
- Universal 2nd Factor (U2F) open authentication standard
- FIDO2 Web Authentication (WebAuthn)
- and now also Kerberos Authentication
Secfense priority is to become a go-to place when it comes to authentication mechanisms deployment. Our mission is to make it possible for organizations and security administrators to easily strengthen authentication security within the entire company.
The main difference between deploying strong authentication mechanisms with Secfense compared with traditional installations is as follows:
- Secfense technology never interferes with protected application code. It works separately and doesn’t touch the application code leaving the application with full independence. The deployment is non-invasive and easy to perform.
- The User Access Security Broker is not tied to any authentication method. This means that security admins and organizations that decide to use Secfense broker have full flexibility of which authentication method to chose. After the Secfense tool is deployed is for the security admin to decide which method should be used on which application and which user group.
- The first two characteristics lead to a third one which is scalability. Since the User Access Security Broker works independently of the application and the deployment is easy and fast it can be easily repeated to any number of apps.
This basically means that organizations that decide to take advantage of Secfense technology can use any strong authentication mechanism and deploy it on all applications and all users within the company.
What else you should know about Kerberos Authentication?
Kerberos is extensively used when it’s necessary to enable single sign-on capabilities within an organization. One of the reasons why Kerberos is so popular is because it has been built into MS Windows for over 20 years. Since Windows 2000 operating system Kerberos was set to be the default authentication package.
Kerberos is also natively integrated and supported by plenty of other major operating systems, including Linux and Unix. There are presently two major versions of Kerberos broadly deployed.
Version four was published in the late 80s and has a major security limitation. It only supports DES, the data encryption standard as the encryption algorithm it uses. DES only supports a 56-bit key, which is not a great option in today’s reality.
Version five is not very recent either. It was first published in 1993 with a revision in 2005. One of the important security improvements in version five is that it now supports various types of encryption and typically the advanced encryption standard AES is used as the encryption algorithm (way better option than DES, its ancestor).
Another significant limitation of both versions of Kerberos is that they only support symmetric cryptography. This leads to major key scaling and distribution problems, especially in a large realm with hundreds or even thousands of systems. The number of keys required grows rapidly, and it can be very challenging to securely distribute all of these keys to the services and the KDC.
There are configurations and implementations of Kerberos that have been made to work with symmetric or public-key cryptography to solve the symmetric key problems. But this is not the default standard version of Kerberos that is natively supported and many OS is in applications.
Deploying Kerberos Authentication with Secfense
If you are interested in checking how Kerberos deployment could look like in your organization or you would like to see how to scale strong authentication mechanisms in your organization you can go ahead and schedule a discovery call with us. On a call, we can show you a live deployment of strong authentication on a web application and explore the best options of strong authentication for your specific scenario.
Disclaimer: The information about Kerberos authentication was heavily based on an amazing walk-through done by Rob Witcher from the Destination Certification Youtube channel. If you want to learn more about Kerberos or CISSP & CCSP Certification content you should visit and subscribe to Rob’s Youtube channel here.
