Kerberos

Kerberos can be used to provide security services for an IP network and has been around for a relatively long time. The early work was done at Massachusetts Institute of Technology during the 1980s and subsequently it went through various stages of standardization in the IETF (Neuman and Ts'o, 1994). Version 5, the current major version, was issued in RFC1510 in 1993. This RFC has stood up well to practical implementation and has needed little modification although there are several more recent extensions. By the way, no introduction to Kerberos seems to be complete without mentioning that the name "Kerberos" comes from the three-headed dog that guarded the gates to Hades in Greek mythology, although which particular hell is guarded in the case of network security is not obvious to us.

Using Tickets

The really good idea in Kerberos is that credentials can be embedded into a special document called a ticket. In much the same way that you can go to Orlando, Florida, and buy a week-long multipark ticket to mouse-related theme parks, a Kerberos ticket provides a network user access to a variety of network services for a limited period of time.^[3]

^[3] Kerberos tickets are service specific, so in practice you would need a set rather than a single ticket.

Let's consider a network of separately administered servers in a large campus using password-based authentication. To access several services, you would need to log in separately to each service, such as the e-mail server, file servers, the database server, printers, and so on. Each time you logged in, your session would be interrupted and you would have to type a password. In the worst case, you would have to know a different password for each service or, if you have a single password, the service itself would have to go back to some central authority to verify your credentials. This approach places the onus on the network servers to check you out every time you ask for access. Checking credentials can be a time-consuming task and, frankly, servers have better things to do with their time.

The situation gets worse if there are different authentication servers for different network domains. Now the server has to go to its local authentication server to check you out and that server might need to go back to your home server to complete the check. As the network grows, this process becomes an unmanageable mess.

Using tickets greatly simplifies the process, which starts with a master access ticket that your computer must get when you first join the network. Before your computer can get the first ticket, you have to prove your identity, in other words, perform master authentication. However, once you are validated, your computer gets the master ticket, establishing a security context. This ticket can now be used to get other tickets specific to the services you want. Your computer can usually handle that task without interrupting you.

Once your computer has a ticket for a particular service, it presents the ticket to that service to get access. Now the onus is on your computer to get the tickets and the load is taken off the services. All the services do is validate a ticket when it is presented, which they can usually do locally and without referring to any other authority.

This description is somewhat simplified, but all the key principles are here. Most of the rest of Kerberos is concerned with ticket management and deals with special cases like cross-domain access and ticket referral (more later). There are a couple of aspects of Kerberos that are problematic (Bellovin and Merritt, 1991).

The first issue is that Kerberos is essentially password based. There have been schemes designed that allow the use of digital certificates with Kerberos, but the predominant model is that of an actual person using the computer. People are able to enter a user password from memory when prompted. Today many network devices are machines, not people; and the password model does not work so well with machines because stored passwords are subject to attack while stored on a machine.

The second issue is that dictionary attacks were not considered a serious threat 20 years ago. In this type of attack, the enemy holds a database with hundreds of millions of passwords the sort of passwords humans tend to make up and various combinations of them. The attack simply involves trying every password. This is a threat if it can be performed offline. In other words, if you can record the messages from an encrypted logon and then go home and run your attack against the recording rather than the real system. Kerberos can be vulnerable to this type of attack unless special steps are taken.

Kerberos Tickets

A ticket is just a piece of data in a special format. All Kerberos tickets have the same basic structure but, to help the explanation, we'll say that there are three types of ticket:

• Ticket-granting

• Service access

• Referral

The introduction to this chapter notes that a master ticket must be obtained before all others. In Kerberos there is nothing quite so strong as a master ticket but, instead, there is a similar concept called a ticket-granting ticket (TGT). The ticket-granting ticket lets you get other tickets from a key distribution center (KDC) for the local security domain (called "realm" in Kerberos).

Obtaining the Ticket-Granting Ticket

When a computer (the client) first connects to the network, it has to contact a KDC to obtain a TGT. The KDC has two parts: an authentication service (AS) and a ticket-granting service (TGS), as shown in Figure 9.7.

Figure 9.7. Authentication Service and Ticket-Granting Service

It is the job of the authentication server to check the client and confirm that it is allowed access to the network. Kerberos uses the approach of shared secrets. The client has some secret information and a copy of this information is stored in a protected user database accessible to the AS. It is expected that the secret on the client side will be stored in the user's head. In other words, there is no copy of the secret password on the computer and a person is expected to remember and enter the password during initial login. After the user enters her password, the client sends a request to the AS asking for a TGT. The request incorporates proof of the secret password. The AS verifies that the secret information matches the copy in the user database and that current security policy allows access. If so, it sends back a TGT to the client.

Once the client possesses the TGT, it can apply to the TGS for tickets to other services on the network. It presents its TGT and indicates which service it wants. The TGS creates and sends a ticket that the client can subsequently present to the service to get access.

Let's pause a moment and look at a few points here. The first question that arises is why bother with the whole TGT concept. If the KDC knows your secret password, why not just go directly to ask for a service ticket using your secret password? If it works to get a TGT, why not do the same for a service ticket? The main reason why the TGT approach is a good idea is that it helps protect the secret information. The right way to do authentication is to use the master password to establish a security context, but then to create temporary session keys for the actual operations. If one of the session keys becomes compromised or discovered, the damage lasts only until you log off or until the lifetime of the key expires. If you were to use the secret password every time you obtained a service key, you would be giving an attacker more chances to attack it. Protection of the master secret is paramount.

The other point is that the user only wants to type the password in once. To avoid the user retyping it all the time, the client computer would have to keep a copy of the password in memory for the duration of the session. If it is stored in memory, it is vulnerable to attack. If you only use the password once to obtain the TGT, you can delete the password from the memory of the client. A similar argument applies on the AS. It has to look up the user in a database to verify the password. It would not want to access the database every time the client requested a ticket so it would have to cache a copy in memory, increasing risk to the password. By generating a temporary key in the TGT, this problem is solved.

Service Tickets

A service ticket must be held by the client until it is presented to the required service. The ticket contains some information that only the service can understand. The client cannot interpret this part of the ticket. When the ticket is sent, the service decodes its own secret part and confirms the client's identity and other credentials. The ticket contains other information, such as period of validity. Like a credit card, it has a start date and expiry date (not in months, of course).

Typically, service tickets last only for a few hours, after which the client must return to the KDC and get a new ticket or renew the existing ticket. Ticket life only affects your ability to log on to the service; once you are in, you stay in until you are logged off, regardless of whether your ticket expires in between (although you might lose critical services, like your file system).

Although we have distinguished TGT and service tickets to help the explanation, in most ways they are the same. The TGS is just a service like any other when it comes to presenting tickets. However the TGS is the only service that can create and issue new tickets. Ordinary services can't create tickets. There are a couple of special cases in which this presents a problem.

Suppose that the service you are using needs to access another service on your behalf. For example, suppose your organization has a special-purpose supercomputer for crunching billions of vector computations a second. You want to use it to process some data that is located on a file server. You can get a ticket to use the Giga-cruncher; but, to do the job, the cruncher needs a ticket to access your data on the file server. This situation can be resolved in one of two ways. The first is known as the proxy method. In this case you, the client, go to the KDC and request a special ticket to allow the Giga-cruncher to access the file server on your behalf. This proxy ticket is then given to the cruncher prior to the job starting. This approach is shown in Figure 9.8.

1. Client obtains ticket for service a.

2. Client presents ticket to service a and gets access.

3. Client obtains proxy ticket for service b.

4. Client gives ticket to service a, which uses it to get access to service b.

Figure 9.8. Obtaining a Proxy Ticket

The second approach is to give the cruncher the right to go to the KDC directly and get tickets on your behalf. You can obtain a special TGT from the KDC, which the cruncher can use to obtain tickets on your behalf. You then give this special TGT to the cruncher. When it realizes it needs access to the file server, it can go and get a ticket just for this purpose. The sequence of events, as shown in Figure 9.9, is as follows:

1. Client obtains ticket for service a.

2. Client presents ticket and obtains access to service a.

3. Client obtains TGT for service a to use on its behalf.

4. Service a obtains ticket for service b using client TGT rights. This is called a forwarded ticket.

Figure 9.9. Use of a Forwarded Ticket

Cross-Domain Access

The discussion so far assumes that there is just one KDC in control of a single security domain called a realm. We have also assumed that the TGS is on the same physical server as the AS. This need not be the case in practice, and there could be one AS and several separate TGS servers. This type of rearrangement is basically transparent to the method. However, accessing services that are in the domain of another AS is a different story and requires special handling.

There are a number of reasons why you might have separate security domains in an organization. Different sites are one reason: An office in Los Angeles would probably be administered separately from an office in London, for example. Domains could also be used at a much lower level, as with university departments. You might be cooperating with another company and you might have decided to give certain employees in the other company access to certain servers in your company.

If an employee of Missiles Galore wants to access a server at partner company Nukes Unlimited, the Missiles employee needs a ticket for the Nukes server. Only the TGS in the Nukes domain can issue tickets for the Nukes servers, but the Missiles employee doesn't have a TGT for the Nukes TGS.

Kerberos handles this situation using referral tickets. The authentication servers at both Nukes and Missiles are configured in advance to allow some users to cross over domains; the two authentication servers share a secret between them. When the computer of the Missiles employee (the client) wants to get to the Nukes file server, it asks its own AS to give it a TGT for Nukes. The local AS cannot do this because it doesn't have the rights to issue such a ticket, but it knows that such access is allowed for this user. So instead, it issues a referral ticket telling the client to ask the AS in the Nukes network directly. This referral ticket is presented to the Nukes AS, which is able to confirm that it was created by its friend, the AS at Missiles. Given that they have an agreement, the Nukes AS then issues a TGT for its own network to the client. The client can use this TGT to obtain service tickets to certain servers on the Nukes network.

How Tickets Work

So far we have only described where tickets come from and what you do with them. We have said nothing about what they contain or why they are secure. A prime requirement of a ticket is that you cannot forge one; that is, make a new one or modify an existing one without permission. Also the service that is presented with a ticket has to be sure it was issued by the TGS and that the client is the valid ticket holder. Not surprisingly, these requirements are achieved by encrypting parts of the ticket with secret keys. Multiple sets of keys can be involved. Let's start from the top when the client first goes to the AS and asks for a TGT.

The client needs to send its identity and its secret to the AS. This is akin to the user name and password of a typical login. The server uses the identity information to look up its own copy of the client's master secret from the user database. To be more correct, the client only needs to prove that it possesses the master password; it doesn't need to send the actual password to the AS. The identity is not considered confidential and is sent in the clear, or unencrypted. The proof of password is achieved by using it to encrypt some value that can be checked by the server. Usually this is a timestamp with the date and time at the moment of sending. The server can decrypt the timestamp with its copy of the client's master secret, and if it produces a sensible value that matches its own clock, it accepts the request. By the way, this is where Kerberos is vulnerable to dictionary attack. An enemy monitoring the link knows, to within a few seconds, the time when the message is sent. Therefore, he can take a copy of the request away and run a dictionary attack by encrypting the known time value with millions of possible passwords until a match is found.

At this point the AS creates the TGT. It generates a new random key that the client and the TGS can use later to protect their communications. This is called the session key and it needs to be delivered securely to both the client and the TGS. The ticket also needs to contain other information for the TGS so it can confirm the identity of the client and so on. This is all accomplished by constructing the response out of two halves. One half is intended to be understood only by the client. The other half is the TGT and is intended to be understood only by the ticket-granting server (Figure 9.10).

Figure 9.10. Kerberos Ticket

This message is sent from the AS to the client. The data is private because both halves are separately encrypted. This is the last time the client's master secret is used until a new TGT is required. The client decrypts its part of the message and stores the session key that will be used to protect the communication with the TGS. It also saves the TGT for later use. Note that it cannot read the contents of the TGT (except the header) because it is encrypted in the TGS's secret. The client doesn't know this secret; it is shared only between the AS and the TGS. Note also that this exchange has provided implicit mutual authentication. The AS confirms that the client knows the master key by checking the time stamp value. The client confirms that the AS knows the master key because otherwise the message returned would not make sense when decrypted.

Now the client is ready to go and get service tickets. It sends the TGT to the TGS with a request for some service. Suppose the client is requesting access to a printer service. The TGS is able to decrypt the ticket and hence finds out the session key for use with this client. It is also able to check that the client is valid and find out other information that was placed there originally by the AS, such as its access rights. With the request, the client also sends the current time encrypted with the session key to prevent replay attacks that is, to stop someone recording the message and playing it back later while pretending to be the client. After the TGS has extracted the session key from the ticket, it can decrypt the timestamp value and check that the request is live and not an old one. Using a rather morbid example, this is like proving that a photograph of a hostage is recent by getting him to hold up to the camera a copy of a current newspaper.

Assuming the TGS is prepared to issue a ticket for the printer, it now repeats the same process that was done by the AS when the TGT was created. It generates a new random session key for use with the printer service and builds a new ticket. This is encrypted with the secret key that is shared between the TGS and the printer. The new session key is encrypted in the current session key and sent back along with the service ticket. Optionally, the TGS can re-encrypt the time value sent by the client so the client can confirm that the message is live and not a replay.

The granting of tickets and their use is iterative. That is, the process of getting and using a TGT is essentially repeated in subsequent service tickets. The client master key is used only at the beginning, and afterwards session keys are used that have a limited life. An attacker has few chances to get at the client master keys. However, as mentioned before, there are a few weaknesses of which to be aware.

The first problem is dictionary attacks. Because the AS reply is encrypted in the client's master key and some fields in the plaintext are known (such as the timestamp), it is possible for a recording of the reply to be taken away and tested against millions of possible passwords. If the user is allowed to choose the password for the master key, sooner or later someone will choose a weak password, such as the name of his dog or where she went on holiday last year. Such passwords will certainly be discovered by an offline dictionary attack. Protection against offline dictionary attack can be provided by mechanisms called zero knowledge password proofs. Examples of such protocols are EKE (Bellovin and Merritt, 1992) and SRP (Wu, 1998) (RFC2945). These protocols are not strictly part of Kerberos V5, and full explanation is beyond the scope of this book. Suffice it to say that the password is mixed up with temporary secret keys that are established for the transfer and discarded afterward. Because an attacker doesn't know the temporary key and it is different on each login, a dictionary attack doesn't give useful information. The downside is that such methods require significant computation resources and are subject to patent licensing requirements.

Another problem with Kerberos is the fact that the identity is sent unencrypted. An attacker can, at least, track which user is accessing the network. Remember that the Kerberos ticket request could be going over a wide area link and, of course, in the case of wireless, such requests will be visible to anyone. Some people think that this lack of anonymity is a problem.

Use of Kerberos in RSN

IEEE 802.11 RSN does not directly specify how to implement Kerberos. It only specifies IEEE 802.1X with its associated use of EAP. As a result, there are several ways Kerberos could be applied. What we describe here is an approach that was proposed by several vendors during IEEE 802.11 standards meetings.

The general picture we have used so far to describe how RSN authentication works has three components in three boxes: the supplicant, the authenticator, and the authentication server (see the discussion in Chapter 8 on IEEE 802.1X/EAP and Figure 9.11).

Figure 9.11. Three-Party Security Model

The RADIUS protocol is needed only if the authentication server is separate from the authenticator and connected by an IP network. For small networks, such as might be used at home, a simple authentication server can be built right in to the access point, eliminating the need for any communications protocol between it and the authenticator (Figure 9.12). In this case the user configures a list of users and passwords directly into the access point and the details of the EAP communications are hidden.

Figure 9.12. Small Network with Built-in Authentication Server

The Kerberos model lies somewhere between the first model (Figure 9.11) and the second (Figure 9.12). But before going on to describe the Kerberos model in detail, we need to work through a few steps.

First of all, consider the situation existing after the client has been authenticated and connected to the network. By then, it has an IP address, and it has obtained a TGT. The client can happily send Kerberos requests to the TGS to get new service tickets. It can submit those new tickets to services and generally go about its business. At this point, Kerberos is being used exactly as it was intended. The tricky part, however, is how to get to this state from startup. How is the authentication performed and how does the access point make a decision to admit the client to the network in the first place?

Now let's look at an interesting concept. As we know, Kerberos tickets allow a client to get access to a service. Previously, we have described services in terms of file servers and printers, but network access could also be considered as a service. As an example, access to the DHCP server that allocates IP addresses could be considered a service that should be provided only to valid clients. The neat concept is to treat the access point itself as a service. In other words, we view the access point as a service that passes data packets to and from a wired LAN. In Kerberos terminology, we would say that, in order to be allowed to use this service, you have to present a valid ticket first. The process of getting connected to the network becomes:

1. Authenticate to the Kerberos AS and get a TGT.

2. Go to the TGS and get a valid ticket for network access (in other words, a ticket to the access point).

3. Present the ticket to the access point, which then confirms its validity and allows you to connect to the network.

This is an attractive concept because it makes the access control for the network just like any other Kerberos service. It has the superb result of simplifying roaming: When the client wants to move to a different access point, it presents the same ticket to the next access point and so on.

Attractive as this may seem, you may be thinking, "Hang on a cotton picking moment … that can't work!" This is a classic example of "which came first, the chicken or the egg?" You need a ticket to get access to the network, but you need access to the network to get a ticket!

In fact, the situation might be even worse. If the client is using DHCP, it won't have an IP address until it can get to the DHCP server. Suppose you need a ticket to get to the DHCP server as well.^[4] The client is stuck: It doesn't have an IP address and, even if it did, it couldn't get to the network to authenticate with the AS anyway because it doesn't have a ticket for the access point. A method has been developed to overcome this deadlock. The solution requires the use of a proxy Kerberos application server residing on the access point (this is just extra firmware). The proxy is a sort of trusted friend connected to the network that can act on the client's behalf.

^[4] It would be unusual to require a ticket for the DHCP server, but we use this as an example because it is analogous to the problem of getting rights to use the access point.

Imagine you go out for the evening and want to enter an exclusive nightclub. The doorman says you can't come in because you are not a member. "So how do I become a member?", you ask. The doorman tells you to apply to the club's owner Luigi. "Where is Luigi?", you ask with a sinking feeling. The doorman tells you that Luigi is at the bar inside the club! What you need in this situation is a friend who is already a member of the club to go in and ask Luigi to give you membership. In the network, the Kerberos proxy is the equivalent of that friend.

Figure 9.13 shows where the proxy resides in the scheme of things. In some ways the picture looks like Figure 9.12, in which the authentication server is in the access point. However, the proxy cannot make the access decision by itself. It can only act as the client's advocate. This is what we meant when we said that the Kerberos case is somewhere between Figure 9.11 and Figure 9.12. The EAP transaction terminates at the proxy, but the authentication is done elsewhere in the network. At the time of writing, the operation of the Kerberos proxy is described in draft-ietf-cat-iakerb-08, an IETF draft titled "Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API (IAKERB)."

Figure 9.13. Use of a Proxy to Obtain Tickets

The opening lines in the abstract of this document read:

This document defines extensions to the Kerberos protocol specification (RFC 1510 [1]) and GSSAPI Kerberos protocol mechanism RFC 1964 [2]) that enables a client to obtain Kerberos tickets for services where the KDC is not accessible to the client, but is accessible to the application server.

This seems to be just what we need. We'll come back to GSS-API shortly, but first let's focus on what the Kerberos proxy does. When the mobile device (client) first comes within range, it connects to the access point. At this stage the IEEE 802.1X controlled port is open (disconnected) so the client cannot communicate with the network. It can, however, communicate to the IEEE 802.1X authenticator, which is closely connected to the Kerberos proxy. The client uses EAP to talk to the Kerberos proxy. In the process the proxy finds out the identity of the client and obtains its secret key information. It can then use this to make a request to the Kerberos AS on the client's behalf. If a TGT is granted by the AS, this can be passed back to the proxy and then to the client. The completion of this phase closes the IEEE 802.1X controlled port. However, in this case there is a second switch in the series that prevents the client getting to the network until it presents a ticket for the access point service, as shown in Figure 9.14.

Figure 9.14. Example Access Point Supporting Kerberos

Referring to Figure 9.14, there are two notional switches that must be closed before data can flow from the client to the network. We say "notional" because, most likely, these are not physical switches but functions buried in software (see Figure 9.14). At the start, both switches are open as shown. All client data packets emerge from the IEEE 802.11 part of the access point and these go to the IEEE 802.1X authenticator and also to the AP service manager. As we know, the IEEE 802.1X authentication listens only to EAP packets; everything else is ignored. The AP service manager is only interested in Kerberos messages and waits to be presented with a valid ticket before it closes its switch.

After the EAP authentication, the IEEE 802.1X switch closes and the client will have obtained a TGT with the help of the proxy. However, it still cannot talk to the network because it has not presented a ticket to the AP service manager. And because the AP service manager is a Kerberos agent, it would also need an IP address to present such a ticket. The services of the proxy are needed several more times.

The client needs one or two more tickets. It needs one for the access point and it may need one for the DHCP server (let's assume so). First, it asks the proxy to obtain a ticket for the access point. The proxy uses the client's TGT to request the access point ticket from the KDC. The ticket is passed back to the client. Now the client asks the proxy to present its access point ticket to the AP service manager. Assuming the ticket is valid, the AP closes the switch and the client can at last talk to the network. However, the client still doesn't have an IP address so it must ask the proxy two more favors: to obtain a ticket for the DHCP server and to present this ticket to the DHCP server. Finally, the client can obtain its IP address and become a full member of the network. It thanks the proxy for the hard work (actually, it doesn't, but that's life) and does all further Kerberos requests for itself.

The IAKERB describes a proxy for use with GSS-API, and the client uses EAP to talk to the proxy. How do these two statements fit together? The approach proposed to use EAP with Kerberos takes advantage of a concept called GSS-API. GSS-API provides an abstract way to define security services. Imagine a team designing an operating system that has secure communications between the application and a remote server. The team has to provide an authentication method, and they have to provide privacy and integrity services linked to the authentication method. The question is, "Which method should they choose?" If they pick one, it may not meet everybody's requirements. That might mean they have to implement several different methods and allow the user to select the method. Worse still, the team knows that in the future new methods are likely to be invented and then they will be faced with upgrading the operating system.

At the risk of being controversial, we should say that if the operating system design team works for a company that owns 95% of the installed base, they may feel comfortable in defining a specific solution and setting that as the benchmark. This more pragmatic approach has been taken in WPA, which simply defines TLS and the mandatory solution. However, let's go back to our more general-minded design team.

All the methods considered by the design team are likely to have some characteristics in common. They must all implement effective authentication. They all have privacy services (in other words, encryption) and they all provide message integrity to prevent forgery. Because these characteristics are common across all methods, the idea was hatched to have a generic interface between the operating system and the security services. This would, in principle, allow the team to plug in security methods according to their needs and avoid the operating system design having to commit to a single approach (see Figure 9.15).

Figure 9.15. Role of GSS-API

The interface by which the communication occurs between the operating system and the security services is called GSS-API, which (finally) we can tell you stands for Generic Security Service Application Programming Interface defined in RFC2743. There is an RFC defining how to use Kerberos with GSS-API (RFC1964) and, importantly from our perspective, there is also a draft that specifies how to use GSS-API in conjunction with EAP. By joining these together, we can now support Kerberos over EAP and hence fit Kerberos into the IEEE 802.1X model.

If you think all of this looks rather complicated, you are not alone. But the complexity lies more in the number of standards and drafts involved in specifying operation rather than in the basic concepts. It is a complexity that is not transferred to the network owner, assuming you are already maintaining a Kerberos-based network.

The main security weakness in the approach comes from the fact that the access points must share a secret with the KDC. This is needed to validate the ticket that is used to gain service from the access point. Apart from being an administrative nuisance to maintain this secret in many access points, it is necessary that the same secret be shared by all the access points if the ticket is to be used for roaming. Such widespread use of a secret is generally frowned upon by security experts. In its favor Kerberos is well known and well tested, it is relatively easy to maintain, and it is the basis of access security for a number of major operating systems, including Microsoft Windows 2000.