Kerberos FAQs

What is Kerberos?

From <http://web.mit.edu/kerberos/www/>

Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography. A free implementation of this protocol is available from the Massachusetts Institute of Technology. Kerberos is available in many commercial products as well.

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 systems crackers. 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. 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.

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. 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 then a computer which is not connected to the network and powered off!) In many places, these restrictions are simply unrealistic and unacceptable.

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. After a client and server have 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.

Kerberos is freely available from MIT, under a copyright permission notice very similar to the one used for the BSD operating and X11 Windowing system. 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. In addition, for those who prefer to rely on a professional supported product, Kerberos is available as a product from many different vendors.

In summary, Kerberos is a solution to your network security problems. It provides the tools of authentication and strong cryptography over the network to help you secure your information systems across your entire enterprise. We hope you find Kerberos as useful as it has been to us. At MIT, Kerberos has been invaluable to our Information/Technology architecture.

Where does the name "Kerberos" come from?

The name Kerberos comes from Greek mythology; it is the three-headed dog that guarded the entrance to Hades.

I see the acronyms TGT and TGS used a lot. What do they mean?

TGT is the acronym for a "Ticket Granting Ticket".

TGS is the acronym for the "Ticket Granting Service".

While it may seen that the two acronyms are used interchangeably, they refer to two very different things. The Ticket Granting Ticket is a Kerberos ticket for the Ticket Granting Service. Both play a special role in Kerberos.

When a user first authenticates to Kerberos, he talks to the Authentication Service on the KDC to get a Ticket Granting Ticket. This ticket is encrypted with the user's password.

When the user wants to talk to a Kerberized service, he uses the Ticket Granting Ticket to talk to the Ticket Granting Service (which also runs on the KDC). The Ticket Granting Service verifies the user's identity using the Ticket Granting Ticket and issues a ticket for the desired service.

The reason the Ticket Granting Ticket exists is so a user doesn't have to enter in their password every time they wish to connect to a Kerberized service or keep a copy of their password around. If the Ticket Granting Ticket is compromised, an attacker can only masquerade as a user until the ticket expires.

What is a "Kerberos client", "Kerberos server", and "application server"?

In Kerberos, all authentication takes place between clients and servers. So in Kerberos terminology, a "Kerberos client" is any entity that gets a service ticket for a Kerberos service. A client is typically a user, but any principal can be a client (unless for some reason the administrator has explicitly forbidden this principal to be a client).

The term "Kerberos server" generally refers to the Key Distribution Center, or the KDC for short. The KDC implements the Authentication Service (AS) and the Ticket Granting Service (TGS). The KDC has a copy of every password associated with every principal. For this reason, it is absolutely vital that the KDC be as secure as possible.

Most KDC implementations store the principals in a database, so you may hear the term "Kerberos database" applied to the KDC.

For reliability purposes, it is possible to have backup KDCs. These are referred to as slave servers. The slaves all synchronize their databases from the master KDC.

In most Kerberos implementations there is also an administration server which allows remote manipulation of the Kerberos database. This administration server usually runs on the KDC.

The term "application server" generally refers to Kerberized programs that clients communicate with using Kerberos tickets for authentication. For example, the Kerberos telnet daemon (telnetd) is an example of an application server.

I use software package <foo>, and it claims it supports Kerberos. What does that mean?

Unfortunately, "supporting Kerberos" can mean a number of things.

The most basic level of Kerberos support is verifying a plaintext password against the Kerberos database. Depending on the application, this may or may not be secure. For example, since the Unix xlock application is designed to verify passwords and (hopefully) is only run from on your local workstation, verifying passwords against a Kerberos database is perfectly adequate. However, if you have a POP server that verifies the PASS command by checking the password against a Kerberos database, that is NOT secure, because the password will travel over the network in the clear.

There are different levels of password verification, however. Unless a program that does plaintext password verification uses the acquired TGT to get a service ticket for a locally trusted service (that is, with the key in a keytab on local disk), then an attacker can spoof the client with a TGT encrypted in a known password.

The next level of Kerberos support is a "true" Kerberized application that uses Kerberos tickets to verify identity and/or encrypt data. This is the way that Kerberos was designed to function, and it provides the highest level of security that Kerberos has to offer. Unfortunately, relatively few applications support Kerberos to this degree.

If you use an application that claims to support Kerberos, you should find out exactly what this means and determine if that is appropriate for your environment. If you use Kerberos primarily as a single-signon system, then having a POP server that verifies plaintext passwords against a Kerberos database may be acceptable to you.

All of the Unix replacement commands that come with the MIT Kerberos distributions (telnet, ftp, rlogin, rsh, etc), are "true" Kerberized applications.

What is cross-realm authentication?

Any Kerberos principal can authenticate to other principals within the same Kerberos realm. However, it is also possible to configure a Kerberos realm so principals in one realm can authenticate to principals in another realm. This is called cross-realm authentication.

The way this is implemented is the KDCs in the two realms share a special cross-realm secret, and this secret is used to prove the identity of principals when crossing the boundary between realms.

Kerberos 5 supports an additional variant of this called transitive cross-realm authentication. In traditional cross-realm authentication, each pair of realms that wish to authenticate need to share a cross-realm secret. This means in a group of N realms, 2 * ((N - 1) ** 2) secrets will need to be exchanged in order to cover all possible cross-realm authentication paths.

In transitive cross-realm authentication you can define a path of realms connected via cross-realm secrets and use this path to "hop" between realms until you get credentials in the desired realm.

Information on configuring cross-realm authentication can be found in the answer to Question 2.15

Are there security risks involved in cross-realm authentication?

When you set up a cross-realm secret, you are in essence trusting the remote KDC to only issue cross-realm tickets for the correct users. If you do not trust the foreign KDC then all principals from the foreign realm are suspect.

However, a realm which you share a cross-realm secret with cannot acquire a ticket for a user in your local realm; a foreign KDC can only cause tickets to be issued that identify users from the foreign realm (in other words, there's no way a KDC can cause a ticket to be generated for a principal in a realm other than it's own).

All of the daemons that come with the MIT Kerberos 5 release do not trust principals in foreign realms by default; you have to explicitly enable them using ACLs. So as long as foreign-realm principals are not on any ACLs in your realm, there isn't a risk.

If you do decide to place foreign-realm principals on ACLs, you will have to remember that the security of that principal depends on the security of the foreign realm.

Are there any known weaknesses in Kerberos?

Kerberos makes no provisions for host security; it assumes that it is running on trusted hosts with an untrusted network. If your host security is compromised, then Kerberos is compromised as well.

However, the degree to which Kerberos is compromised depends on the host that is compromised. If an attacker breaks into a multi-user machine and steals all of the tickets stored on that machine, he can impersonate the users who have tickets stored on that machine but only until those tickets expire.

Kerberos uses a principal's password (encryption key) as the fundamental proof of identity. If a user's Kerberos password is stolen by an attacker, then the attacker can impersonate that user with impunity.

Since the KDC holds all of the passwords for all of the principals in a realm, if host security on the KDC is compromised, then the entire realm is compromised.

In Kerberos 4, authenticators are valid for 5 minutes. If an attacker sniffs the network for authenticators, they have a 5 minute window in which they can re-use it and gain access to the same service you used. Kerberos 5 introduced a replay cache which prevents any authenticator from being used more than once.

Since anybody can request a TGT for any user, and that ticket is encrypted with the user's secret key (password), it is simple to perform a offline attack on this ticket by trying to decrypt it with different passwords. Kerberos 5 introduced preauthentication to solve this problem.

What is "user to user" authentication?

User-to-user authentication is a special Kerberos application protocol, that allows users to host secure application services on their desktop machines. It is increasingly common for users to offer desktop services that merit secure authentication, such as nfs and ftp. When users configure their desktop servers with a long-lived srvtab key, this long-lived key becomes a very attractive target for theft. User-to-user authentication enables a user to run a server without keeping a long-lived key on disk. Instead, the user's short-lived TGS session-key takes the place of the usual srvtab secret key, in the server's authentication handshakes.

Authentication in Kerberos happens between a client and server. The client gets a ticket for a service, and the server decrypts this ticket using its secret key. This works fine for a physically- secure server, which keeps its secret key on its local disk. But, storing the server's key on disk doesn't work for services that run on users' desktop machines, since no-one should keep a long-lived secret key on an insecure disk drive.

The solution to this problem is called user-to-user authentication, and it is implemented in Kerberos 5. In the user-to-user protocol, one user acts as a server, and the other user acts as a client. at the client-user's request, the server-user sends his TGT (but not his session key) to the client-user, who then gets credentials from the KDC, encrypted with the session keys of both TGTs. Both users can decrypt the new session-key and use it to verify each other's identity. The advantage of the U2U scheme is that the server-user exposes only his short-lived TGS session-key to theft; he keeps his long-lived secret, his password, in his biological memory. An attacker is less likely to bother to steal a short-lived server-key. However, U2U's downside is that the desktop server cannot operate autonomously; the service-operator has to refresh his TGT in order for the server to keep accepting clients' requests.

Applications have to handle user-to-user authentication as a special case; Kerberos 5 does not offer an API that hides the difference between desktop servers and physically-secure servers. For this reason, very few services currently support the user-to-user protocol. The user-to-user protocol was originally designed for authenticating X-windows sessions, where the server usually runs on an insecure desktop machine. See Question 3.10 for more information on this.

What are forwardable tickets?

Inside of the Kerberos ticket is encoded the IP address of the client. This is used by application servers and the KDC to verify the address of the client. This means that a ticket that was acquired on one host cannot be used on another.

Kerberos 5 introduced the concept of forwardable tickets. During the initial TGT acquisition, a client can request that the ticket be marked forwardable. If the KDC chooses to honor this request (the administrator has the option of disallowing forwardable tickets on a per-site or per-principal basis), the TKT_FLG_FORWARDABLE flag will be set in the flags field in the ticket.

Once the TKT_FLG_FORWARDABLE flag is set on a ticket, the user can use this ticket to request a new ticket, but with a different IP address. Thus, a user can use their current credentials to get credentials valid on another machine.

What are renewable tickets?

One practical problem with Kerberos is that the tickets eventually expire. A practical balance has to be made between the desire to reduce the usefulness of stolen tickets (short lifetime) versus the ease-of-use for the user (long lifetime).

This problem becomes a much larger issue when dealing with long-running user processes. Jobs run on some supercomputer systems can run for days or weeks, but having tickets that last that long can be a security nightmare.

The compromise for this problem that was introduced in Kerberos 5 is the support for renewable tickets. Renewable tickets have expiration times, like normal tickets. However, they also have a maximum renewable lifetime.

A renewable ticket can be renewed by asking the KDC for a new ticket with an extended lifetime. However, the ticket itself has to be valid (in other words, you cannot renew a ticket that has expired; you have to renew it before it expires). A renewable ticket can be renewed up until the maximum renewable ticket lifetime.

This scheme has two important advantages over long-lived tickets:

1. It reduces the window of usefulness for stolen tickets. If an attacker gets access to a renewable ticket after it has expired, then it is useless. 2. After a user is finished with a renewable ticket, he can notify the KDC that he no longer needs the ticket, and the KDC will refuse to renew this ticket any more (note that although this is in the protocol, I don't think any version of Kerberos actually implements this part).

What are postdatable tickets?

Normally, a ticket is valid starting from the time you request it until it expires.

However, there may be some cases where a user would like a ticket that is valid some time in the future. For example, a user may wish to run a batch job next week, but your maximum ticket lifetime is only one day.

To accommodate this need, Kerberos 5 introduced postdatable tickets. These are tickets which are initially invalid, and have a starting time some time in the future.

To use a postdatable ticket, the user must send it back to the KDC to have it validated during the ticket's valid lifetime.

What are the advantages/disadvantages of Kerberos vs. SSL?

In brief, the question seems to be, "What does Kerberos give me that SSL doesn't?"

That question is specific case of the general question, "What are the advantages and disadvantages of a private-key, trusted-third-party authentication system vs. a public-key, certificate-based authentication system?"

As I see it, SSL has two major advantages over Kerberos: (1) It doesn't require an accessible trusted third party; (2) it can be used to establish a secure connection even when one end of the connection doesn't have a "secret" (a.k.a. "key" or "password"). These two advantages make it ideal for secured Web communication and for similar applications where there is a large user base which is not known in advance.

Here are some disadvantages of SSL:

1) Key revocation. If a Verisign certificate issued to a user is compromised and must be revoked, how will all the servers with whom that user interacts know that the certificate is no longer valid? Either revocation certificates have to be circulated to all relevant servers and cached for a long time, or servers have to verify incoming user certificates against a "revocation server." In that case, the revocation server must be a highly available third party, which means you've eliminated one of the two major advantages of SSL over Kerberos. Kerberos principals can be disabled at will on the KDC and will then become unusable as soon as any cached tickets expire, on the order of hours, without any action by servers.

2) Key security. If I'm issued a Verisign certificate, it has to live on my hard disk. Yes, it may be encrypted there such that I have to unlock it with a password before I can use it, but it's still on the hard disk and therefore vulnerable to cracking attacks. On the other hand, I don't need any sort of certificate to authenticate to Kerberos all I need is my password, which is in my brain, not on a hard disk.

3) Cost of use. Kerberos doesn't infringe on any patents. Which means that it can be used for free, while SSL users may have to pay.

4) Open standards. Kerberos has been free from the beginning. The standards documenting it are open and have been developed openly from the start. On the other hand, SSL was developed by a company with a commercial interest in ensuring that its standards become THE standard. Let's just say that Netscape is not exactly known for "playing by the rules" when it comes to developing Internet standards.

5) Flexibility. I'm under the impression, although I may be wrong (if so, I hope someone will correct me), that Kerberos is somewhat more flexible than SSL. For example, if I want to add a new authentication technology to Kerberos (e.g., a new kind of SmartCard with its own algorithm), all I have to do is modify my KDC and my ticket-acquiring client to know how to do the new authentication. Then, it can be used to get Kerberos tickets which will look the same as any other Kerberos tickets and will be usable with any Kerberos-capable application. On the other hand, if I want to implement a new authentication technology for SSL, I believe I'd have to get new versions of all my SSL-capable applications.

I'm probably forgetting some advantages and disadvantages of Kerberos and SSL, but my object here isn't to be comprehensive. My point is that there are applications for which SSL is superior to Kerberos and vice versa.

What are proxiable tickets?

In addition to forwardable tickets, Kerberos 5 introduce the concept of proxiable tickets. A proxiable ticket is a ticket (generally only a TGT) that allows you to get a ticket for a service with IP addresses other than the ones in the TGT.

This is different than forwardable tickets in that you cannot proxy a new TGT from your current TGT; you can only proxy non-TGT service tickets. In other words, forwardable tickets let you transfer your complete identity (TGT) to another machine, where proxy tickets only let you transfer particular tickets.

In general practice, proxiable tickets are not used that often.