UNDER ATTACK

Perhaps the simplest way to break into a network is to steal passwords. With any broadcast LAN technology such as Ethernet or Token Ring', passwords are transmitted so that anyone can collect and display them with a protocol analyzer or other direct data capture device. On an Ethernet LAN, with the proper software, almost tiny workstation can be put into a promiscuous mode, allowing the user to look at all traffic on the local network. Although multiuser systems usually require a user to have certain privileges to gain such access, one must assume that intruders can obtain the necessary level of access, or even hook up their own workstations which would not be subject to the restrictions of the multiuser system.

Once an intruder gains access to network traffic, it's a simple matter to sift through the sea of data and capture passwords transmitted in clear text (i.e., as unencrypted characters) by remote login protocols such ils Telnet and file transfer protocols such as FTP. Another common means of attack is via the Unix remote services, such RLOGIN and RSHELL. One problem with these protocols, from a security standpoint, is that they allow users to hop from machine to machine, gaining each machine's security rights as they go. Suppose, for instance, that machine "queen" has access to machine "king," and machine "prince" has access to machine "queen." A perpetrator who manages to break into "prince" can get to "king" by going through "queen." This possibility means that the system administrator at "king" not only has to worry about trusted "queen," but also about everyone that "queen" trusts and everyone they trust and so on. In a large network, monitoring this chain of trust can be an impossible task.

Another problem with remote ser-vices is spoofing, or imitating IP addresses. Although the remote proto-cols do not transmit users' passwords on the network, they identify trusted machines by their network addresses. A perpetrator can disable the real trusted machine and impersonate it using its IP network address. (You can't impersonate a trusted machine while it's on the network, since duplicate IP addresses are not allowed.)

The challenge is not just to plug such security leaks but also to prevent them from occurring in the first place.

 WHAT CAN YOU DO?

The principal problem with computer networks is that they cannot be trusted. You must assume that any-thing transmitted on the network can be heard by anyone and anything received from the network can be manufactured by a potential intruder.

Any truly secure protocol must make it possible to determine the true identity of a user who provides a false user name. The basis for making this identification is a password. The protocol must also protect sensitive password information, even if all communication with the entity is public. Kerberos is such an authentication protocol.

Named after the mythical three-headed dog that guards the gates of Hades, Kerberos is a product of Massachusetts Institute of Technology's Project Athena. MIT has a campus-wide, public network that includes a variety of workstations and servers. Any workstation can potentially be used to scan network traffic, so sending users' passwords on the network would be a high security risk. Kerberos was developed so that servers could authenticate users.

Kerberos provides authentication, not authorization. Authentication determines who someone is; authorization determines what someone can do. Authentication is a prerequisite to authorization, but it is up to the particular server to decide which ser-vices and files a user may access once his or her identity has been verified.

 WHO'S KNOCKING ON MY DOOR?

Given that we can't trust the network to verify a user's identity, how do we prove a user's identity to the server'? The Kerberos solution employs shared secrets, Data Encryption Standard (DES) encryption, and a system of tickets that allow a user to prove his identity to a server via a third party, namely the Kerberos server.

The shared secrets are keys. A key is a string of characters used to encrypt a message, that is, to turn the message into an unintelligible series of characters. You can decrypt the message (turn it back into clear text) only if you also know the same key. Some keys are persistent, that is, they stay the same until someone changes them. For instance, there's a client key and a server key which are persistent. Persistent keys are usually known only to the entity they belong to and to Kerberos. Session keys, in contrast, are only good for one communications session. After that, they're tossed out. Session keys may be known to Kerberos and two other entities, such as the client and the server. In this article, we'll refer to a session key between Joe and Tom as the (Joe, Tom) key, so you can keep them straight. A persistent key will be referred to simply as the server key or the client key.

The ticket-getting process is much like getting a driver's license. The Ticket-Granting Service (TGS) on the Kerberos server issues the driver's license, and the client uses it to prove its identity to the target server (the server the client wants to access). Kerberos is a little more demanding than the Department of Motor Vehicles (DMV) in that it requires you to get a new license for each destination (each server). On the plus side, Kerberos licenses take only a few seconds to get, and you don't have to leave your desk.

Before the client can apply for the driver's license, though, the client's password has to be entered into a database at the Kerberos server, where it is permanently stored in encrypted form. That encrypted password is the client key. Both the client password and the client key are critical parts of the system. Password entry should be done in a completely secure fashion, and the Kerberos server should be protected so no one can access the keys.

Now, let's say Joe sits down at a workstation and types in his password to log on to a particular target server. The client software running at Joe's workstation sends a request to the Key Distribution Center (KDC) on the Kerberos server. The KDC is the network equivalent of the DMV. The client software first asks the KDC to issue a "ticket-granting ticket," provided by the Ticket-Granting Ticket (TGT) service (sec Figure 1). The ticket-granting ticket's purpose is to let you get tickets from the TGS, so it might he easier to think of it as a ticket-getting ticket. In our example, the ticket-getting ticket proves to the TGS that Joe is who he claims to be.

The KDC responds with a message encrypted in the client key, which is derived from Joe's password. The message contains a ticket-getting ticket which allows the client to use the TGS, and a (TGS, client) key which is now a shared secret between the TGS and the client software.

The client decrypts the KDC's message, using the client key. Then the client has the ticket-getting tick-et, which it uses to request tickets from the TGS. Since that client key is derived from Joe's password, the ability to decrypt the KDC message and obtain the ticket-getting-ticket proves to the TGS that Joe gave the right password. Thus, Joe has proved his identity without ever sending his password across the network, in fact, even the client key never went across the network only messages encrypt-ed with the client key.

Now the client software can send requests to the TGS, encrypting them in the (TGS, client) key, which it just got from the TGT service. The TGS provides tickets for the services that the user really wants to use (see Figure 2).

However, the TGS will not accept just the ticket-getting ticket itself as proof positive that it's talking to Joe. It's possible that a snooper could steal the ticket-getting ticket and use it to get illegal tickets for servers. 

To prevent this possibility, the TGS re-quires the client to send an authenticator along with the ticket-getting ticket (see Figure 3). The authenticator consists of a time stamp and Joe's address and user name, all encrypted with the (client, TGS) key. The TGS decrypts the ticket using the TGS server key. Then it decrypts the authenticator, using the (client, TGS) key, which it got from the ticket. The TGS compares its internal clock to the time on the time stamp in the authenticator. In version 4 of Kerberos, the two had to be within about five minutes of each other--a necessary compromise since clocks on different machines may not be precisely synchronized. However, this compromise means that a thief could steal a ticket-getting ticket and an authenticator and submit them both to the TGS within five minutes of their original submission and thus gain illegal access to a service. With version 4 of Kerberos, programmers creating Kerberos implementations for servers can save authenticators for five minutes and refuse to accept the same authenticator twice. The code for implementing such an "authenticator cache" isincluded with version 5 of Kerberos. Although each user needs only one ticket-getting-ticket for each logon session, a separate ticket is required for each service on each separate server machine. Two separate tickets would be required to access the RLOGIN services on machines foo and bar, and two separate tickets would be required for the RLOGIN and ADMIN services on machine spare. The requirement for a new ticket for each server breaks the "chain of trust" inherent in the remote protocols. Get-ting into "prince" docs not get you to "queen," and getting into "queen" docs not get you into "king." Instead, Kerberos keeps track of the servers you may access and only lets you into those servers.

Once the ticket-getting ticket is obtained, however, the client software will automatically obtain tickets for services on servers as needed, without user intervention. So Joe doesn't need to sec anything more than an initial request for his password.

Joe provides his password just once. Requests to the TGS use the (client, TGS) key and the ticket-getting ticket, not the password. The Kerberos client software minimizes exposure of the user's password, even zeroing out the client's memory where the password is read. Thus, even it' an intruder were using a system memory analyzer, he or she would have only a fraction of a second to spy the user's password before it wits erased.

The TGS sends a response to the client that contains a ticket and a (client, server) key. The ticket contains information that proves it was issued by the official TGS, just as a driver's license picture may be overlaid with a difficult-to-forget pattern to prove that the driver received the license from the DMV. The ticket contains the names of the client and server, the client's network address, a time stamp, a lifetime for the ticket, and a (client, server) key. The ticket is encrypted in the server key (which the TGS also knows), so the client can't decrypt it.

Note that the (client, server) key appears twice, once separate from the ticket and once inside the ticket. The client can't get it the one inside the ticket, because the ticket is encrypted in the server key, which is known only to the server and the TGS. That's why the TGS sends the (client, server) key outside the ticket as well.

The ticket is the client's driver's license. The client needs to send that driver's license to the target server. Normally, the server would provide a service like Telnet or RLOGIN. In Joe's case, he's been studying the Kerberos protocol and has a headache. Luckily, his network contains an aspirin server which will dispatch first, fast, fast relief to his desk, if only he can prove his identity. But the client can't just send the ticket across the network, because tickets may be good for an extended period of time, perhaps several hours. A snooper might capture the ticket, store it, and "replay" it later to get access to the server. So the client sends both the ticket and an authenticator, just as it did originally with the TGS.

Once the server confirms that the ticket is legitimate and the authenticator recent, it grants the service, Joe gets his aspirin, and everyone's happy. Except possibly Joe. Being deep into the science of network security, he is paranoid and fears that a treacherous placebo server may have disabled the aspirin server and may now be impersonating it. Joe sent off his ticket and authenticator and a bottle marked "aspirin" arrived at his desk. But how can he know it's the real thing?

So far, the (client, server) key has been used to authenticate the client. For instance, the fact that the (client, server) key in the ticket successfully decrypts the authenticator proves to the server that the authenticator was encrypted with the (client, server) key. That proves that the client who encrypted the time stamp is the same client that got the ticket. That means the client successfully proved Joe's identity to the Kerberos server.

The client can also use the (client, server) key to authenticate the server. To do this, the client issues a challenge which consists of a random number, usually a time stamp, encrypted in the (client, server) key. The server decrypts the challenge, increments the time stamp by one, then encrypts the new number using the (client, server) key and sends it back to the client. After the client decrypts this response, it' the value of the returned number is one greater than the original number, then the server has demonstrated that it knows the (client, server) key. That means it was able to decrypt the ticket, which means it knows the server key and must be the legitimate server.

CARE AND FEEDING OF KERBEROS

The KDC is the keystone of the entire Kerberos network authentication sys-tem. The network is no more secure than the KDC machine. Keeping that machine (or machines, since it is advisable to have multiple KDCs to ensure a high level of availability) in a locked and guarded room is not an undue precaution. Although some may consider it a design shortcoming of Kerberos that there is a single point of attack, there is an advantage to it, too: you can concentrate your security efforts on protecting the KDC.

The database is administered using programs that are either run on the KDC machine or on an administration server that is accessed by client programs run on workstations. Users authorized to modify the KDC database must be trustworthy, since they can grant any level of access to any machine on the network that depends on Kerberos for authentication. To simplify management, normal users are able to change their own passwords so the database administrators aren't burdened with ongoing changes.

Like the KDC machine, the KDC's database needs to be protected. The ability to modify the database would almost certainly allow an intruder to break into any machine on the network. Although breaking in to read the KDC database would constitute a somewhat lesser breach of security, at the very least it would provide a comprehensive list of user names (which would be very useful for a password-guessing attack). However, the intruder could not get the users' passwords from the KDC database, since passwords are stored only in an encrypted form.

 NOTHING IS PERFECT

Kerberos offers a very nice distributed authentication service. It certainly is a better way to prove a user's identity to a server than with the network equivalent of shouting passwords across a crowded room. But using Kerberos cannot guarantee that your network and machines will never be burglarized. First and foremost, the cleverest authentication scheme will not provide much security if a thief can get or guess users' passwords. Kerberos does prevent spying someone's password by just snooping on the network, but users must still be educated so that they choose passwords that are difficult to guess and so that they don't give their password to anyone, even someone claiming to be a new system administrator.

There are other ways to impersonate a user, even on a Kerberos-protected system. Attacks can be based on replaying authenticators previously spied on the network, which is difficult since an authenticator typically has a five-minute lifespan. However, an attacker could fool the network time service so that an expired authenticator can be used. As such attack strategies are discovered, however, defenses to counter them tire being developed and incorporated into subsequent versions of the Kerberos protocol and code.

Of course, other attacks can be made on a networked environment that Kerberos cannot secure against. For instance, an intruder can leave a program running at a public workstation that appears to be the normal login screen but really stores the user name and password as they are typed in. When an unsuspecting user walks up to the workstation and types his user name and password, then that user's security has been completely violated. This sort of a attack can be prevented only by fairly extreme measures such as carrying around a portable PC and never using a public workstation, or through physical proofs of identity such as thumbprint readers.

Basically, a clever and determined computer crook can break into any-thing. But you can at least make it harder to break in than walking through an open front door. Using an authentication approach such as Kerberos, you cannot only lock the front door, but you have a fairly good watchdog guarding that door.