SecureBlackbox 16: Kerberos vs. SSL/TLS

This article introduces Kerberos and SSL/TLS along with their intended uses.

Content

• What is Kerberos?
• What is SSL/TLS?
• How Kerberos Works
• Kerberos as a Single Sign-On System
• Drawbacks of Kerberos
• How TLS Works
• Uses of TLS and Kerberos

What is Kerberos?

Kerberos is a protocol for authentication between nodes in a computer network over nonsecure 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. The 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 at the Massachusetts Institute of Technology (MIT) and was implemented in a software product of the same name, Kerberos. Some confusion stems from the fact that there are several programs with similar names. Typical questions include "Why does Kerberos use SSL?" and "Is SSL a part of the Kerberos protocol?"

SSL is not part of the Kerberos protocol, but software that uses Kerberos for client and server authentication may use SSL as well.

For example, SecureBlackbox 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 secure communication over a nonsecure 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 the integrity of the data transferred, provides nonrepudiation, and certifies the source of this data. As a rule, but not necessarily, it encrypts the data.

This protocol is implemented in various applications (web browsing, email, instant messaging, voice-over-IP, etc.) and other protocols (such as FTPS).

SecureBlackbox offers SSL/TLS as an 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 the Netscape Corporation.

How Kerberos Works

Kerberos is based on symmetric encryption and a trusted third party, but not the same as in the 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 underlying Kerberos is not to send passwords over the network; instead, a hash of the user's password is sent and checked on both sides of the connection, and the password itself is used as a key for symmetric hash encryption. A time-stamp is added to the encrypted hash. The security of the protocol relies on the 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.

Kerberos relies on a trusted third party, which is called a key distribution center (KDC) that consists of 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 a Ticket Granting Ticket (TGT). It then contacts the Ticket Granting Server, and using the 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.

Kerberos as a Single Sign-On System

Kerberos is a single sign-on system, which means that a client logs in only once and then gains access to services without the need to log in each time he or she 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 the initial authentication.

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

SSO uses the 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.

Drawbacks of Kerberos

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

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

• Strict time requirements: 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 authentication is controlled by a centralized KDC, compromise of this infrastructure will allow an attacker to impersonate any user.

How TLS Works

The TLS protocol does not 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. The security of TLS is based on public key, symmetric key, and MAC cryptographic algorithms. Communication starts with the procedure called the handshake. During the handshake, client and server negotiate 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 to refresh symmetric keys. If any one of the above steps fails, the TLS handshake is considered to be unsuccessful and the connection is not created.

Uses of TLS and Kerberos

Kerberos and TDS are intended for use in disparate scenarios: If you want to secure your communications in the sense that nobody can read it or tamper with it, perhaps the right choice is to use TLS or some other protocols based on it. A good example is the use of TLS in the HTTPS protocol, which secures traffic on the World Wide Web. For secure file transfer, you can use FTPS. For secure mail transfer, secure SMTP with TLS.

If you need to manage user access to services, you may want to use Kerberos. You describe the user rights and your administrative policy in the Authentication Server.