Kerberos vs. SSL/TLS. What’s the Buzz?

Sometimes you can hear or read a question: what is the difference between Kerberos and SSL? Which is better? What to prefer? It's a bad question. Let's better talk about common features: what is common in Kerberos and SSL? The answer is: almost nothing. In this article we will talk about main features of Kerberos and SSL, which is actually TLS (explanation follows), and what to use depending on situation and your demands.

Content

What is Kerberos

Kerberos is a protocol for authentication between nodes in a computer network over non-secure lines. It allows nodes to prove their identity to one another in a secure manner. It is aimed primarily at a client-server model, and it provides mutual authentication - both the user and the server verify each other's identity. It is important to understand that Kerberos may be used to authenticate a client to several different servers at the same time. Kerberos protocol messages are protected against eavesdropping and replay attacks.

Kerberos authentication is widely used in Microsoft products like Windows 2000 and later Windows NT-based operating systems. Cross-platform Active Directory integration vendors have extended the Integrated Windows Authentication paradigm to UNIX, Linux and Mac systems.

The protocol was designed in Massachusetts Institute of Technology (MIT) and was implemented in a software product of the same name, Kerberos. There are several programs with similar names, which produce some kind of misunderstanding: sometimes people get confused and ask why the Kerberos program uses SSL? Is SSL a part of Kerberos protocol?

No, it is not. But software that uses Kerberos for client and server authentication may use SSL as well.

For example, SecureBlackbox developed by EldoS Corporation uses Kerberos for client authentication through GSS-API (Generic Security Services Application Program Interface), which is the standard mechanism to access security services for the C (RFC 2744) and Java (JSR-072) languages.

What is SSL/TLS

SSL, which stands for Secure Socket Layer, is a cryptographic protocol that provides communication security over non-secure network. SSL is an obsolete protocol; its modern version is called TLS (Transport Layer Security). TLS and SSL encrypt the segments of network connections, using symmetric cryptography for privacy and a keyed message authentication code for message reliability.

TLS provides security in a sense that it proves integrity and non-repudiation of data transferred, and certifies the source of this data. As a rule, but not necessary it encrypts the data.

This protocol is implemented in various applications such as for web browsing, electronic mail, instant messaging, and voice-over-IP (VoIP). Some other protocols (e.g. FTPS) use TLS to extend their capabilities.

EldoS Corporation has developed SecureBlackbox library that offers SSL/TLS as independent transport layer and as a part of transport protocols like FTPS, SSH and SFTP. The last two support authentication with the help of GSS-API, which means they can use Kerberos.

TLS is an IETF standards track protocol, last updated in RFC 5246 and is based on the earlier SSL specifications developed by Netscape Corporation.

How Kerberos Works

Kerberos is based on the symmetric encryption and a trusted third party, not the same as in PKI scheme; at least the original version of protocol does so. Starting from version 5, the protocol has been extended with asymmetric encryption capabilities, including support for public and private keys, as well as for digital certificates of Public Key Infrastructure.

The main idea lying under Kerberos is not to send passwords over the network; instead hash of the user password is send and checked on both sides of connection, and the password itself is used as a key for symmetric hash encryption. Time-stamp is added to encrypted hash. The security of the protocol relies on assumption that participants have loosely synchronized time (the clock difference must be not more than 5 minutes) and on short-lived assertions of authenticity called Kerberos tickets.

Single Sign-On

Kerberos is a single sign-on system, which means that a client logs in only once, and then gains access to services without need to log in each time he wants a new service. In general, various applications and resources support different authentication mechanisms, so the single sign-on system has to internally store its credentials, which are compared to what is used for initial authentication.

Single sign-on systems have several benefits, in particular they reduce time spent for re-entering passwords for the same identity; they reduce phishing success, because users are not trained to enter password everywhere without thinking; they reduce password fatigue from different user name and password combinations.

SSO uses centralized authentication servers that all other applications and systems utilize for authentication purposes, and combines this with techniques to ensure that users do not have to prove their credentials more than once.

It is also important that SSO users need not remember too many passwords to login to different systems or applications.

Brief Description of Kerberos

Security in Kerberos relies on a trusted third party, which is called a key distribution center (KDC) that consists on two logically separate parts: an Authentication Server (AS) and a Ticket Granting Server (TGS). Kerberos works on the basis of “tickets”, which serve to prove the identity of users. The key distribution center maintains a database of secret keys (passwords); each entity on the network - whether a client or a server - shares a secret key known only to itself and to the KDC. Knowledge of this key serves to prove an entity's identity. For communication between two entities, the KDC generates a session key, which they can use to secure their interactions

The client authenticates itself to the Authentication Server and receives a time-stamped ticket, called Ticket Granting Ticket (TGT). It then contacts the Ticket Granting Server, and using TGT it demonstrates its identity and asks for a service. If the client is eligible for the service, then the Ticket Granting Server sends another ticket to the client. The client then contacts the Service Server, and using this ticket it proves that it has been approved to receive the service.

Drawbacks

There are several known drawbacks of Kerberos protocol, among which are the following.

Single point of failure: it requires continuous availability of a central server. When the Kerberos server is down, no one can log in.

Kerberos has strict time requirements, which means the clocks of all principals must be synchronized. The tickets have a time availability period and if the host clock is not synchronized with the Kerberos server clock, the authentication will fail. The default configuration per MIT requires that clock times are no more than five minutes apart. In practice Network Time Protocol daemons are usually used to keep the host clocks synchronized.

The administration protocol is not standardized, and differs between server implementations. Password changes are described in RFC 3244.

Since all authentications are controlled by a centralized KDC, compromise of this infrastructure will allow an attacker to impersonate any user.

How TLS Works

TLS protocol doesn’t assume the authentication process in a form of login or sign on. It is designed to provide secure data exchange between client and server and to prevent eavesdropping and data tampering. Security of TLS is based on public key, symmetric key and MAC cryptographic algorithms. Communication starts with the procedure called handshaking. While handshaking client and server negotiate to agree on various parameters used to establish the connection's security.

  1. The handshake begins when a client connects to a TLS-enabled server requesting a secure connection and presents a list of supported ciphers and hash functions.
  2. From this list, the server picks the strongest cipher and hash function that it also supports and notifies the client of the decision.
  3. The server sends back its identification in the form of a digital certificate. The certificate in particular contains the server name, the trusted certificate authority information and the server's public key.
  4. Before proceeding, the client may use tools provided by the PKI to ensure that the provided certificate is valid.
  5. In order to generate the session keys used for the secure connection, the client encrypts a random number with the server's public key and sends the result to the server. Only the server should be able to decrypt it, with its private key.
  6. On the basis of this random number, and other information the parties exchanged during the handshake, they generate shared symmetric keys for data encryption and decryption.

This concludes the handshake and begins the secured connection, encrypted and protected with symmetric and MAC keys negotiated by the parties during the handshake. Each of the parties may request key renegotiation in the middle of data transfer in future to refresh symmetric keys. If any one of the above steps fails, the TLS handshake is consider being unsuccessful and the connection is not created.

Summary

Kerberos and TLS are not things to compare. They have different objectives and different methods. In the beginning of our article we mentioned some of the mos frequent asked questions like “which is better” and “which to choose”. The former is not a question at all: nothing is better and everything is good if you use it in a right way. The latter question is worth a serious consideration: what to choose depends on what you have and what you want.

If you want to secure your communications in a sense that nobody can read it or tamper it, perhaps the right choice is to use TLS or some other protocols based on it. A good example of TLS usage for securing World Wide Web traffic carried by HTTP is to use HTTPS. For secure file transferring you may use FTPS, and take into account that SMTP (though it stands for a “simple” mail transfer protocol, not “secure”) may also be protected with TLS.

On the other hand, if you need to manage user access to services, you may want to use Kerberos. Imagine, for example, that you have several servers like Web server, FTP, SMTP and SQL servers, and optionally something else, everything on one host. Some clients are allowed to use SMTP and HTTP, but not allowed to use FTP, others may use FTP but don’t have access to your databases. This is exactly the situation when Kerberos comes to use, you just have to describe the user rights and your administrative policy in the Authentication Server.

Ready to get started?

Learn more about SecureBlackbox or download a free trial.

Download Now