Euripides: You've got rings under your eyes this morning.

Athena: Well, you know. Another one of those long nights.

Euripides: Have you solved the replay problem?

Athena: I think so.

Euripides: Have a seat.

She does.

Athena: As usual, I feel compelled to restate the problem. Tickets are reusable within a limited timespan, say eight hours. If someone steals your tickets and chooses to replay them before they expire, we can't do anything to stop them.

Euripides: That's the problem.

Athena: We could beat the problem if we designed the tickets so they couldn't be reusable.

Euripides: But then you would have to get a new ticket every time you wanted to use a network service.

Athena: Right. That is a clumsy solution at best. (Pause.) Ah, how do I proceed with my argument? (She ponders for a moment.) All right, I'm going to restate the problem again, this time in the form of a requirement. A network service must be able to prove that the person using a ticket is the same person to whom that ticket was issued. Let me trace the authentication process again and see if I can tease out an appropriate way to illustrate my solution to this problem. I want to use a certain network service. I access that service by starting a client program on my workstation. The client sends three things to the service machine-- my name, my workstation's network address, and the appropriate service ticket. The ticket contains the name of the person it was issued to and the address of the workstation that person was using when he or she acquired the ticket. It also contains an expiration date in the form of a lifespan and a timestamp. All this information has been encrypted in the service's Charon password. Our current authentication scheme relies on the following tests: Can the service decrypt the ticket?

Has the ticket expired?

Do the name and workstation address specified in the ticket match the name and address of the person who sent the ticket? What do these tests prove? The first test proves that the ticket either did or did not come from Charon. If the ticket cannot be decrypted, it did not come from the real Charon. The real Charon would have encrypted the ticket with the service's password. Charon and the service are the only two entities that know the service's password. If the ticket decrypts successfully, the service knows that it came from the real Charon. This test prevents folks from building fake Charon tickets. The second test checks the ticket's lifespan and timestamp. If it has expired, the service rejects the ticket. This test stops people from using old tickets, tickets that perhaps were stolen. The third test checks the ticket-user's name and address against the name and address of the person specified in the ticket. If the test fails, the ticket-user has obtained (perhaps surreptitiously) another person's ticket. The ticket is of course rejected. If the names and addresses do match, what has the test proved? Nothing. Scallywags can steal tickets from the network, change their workstation addresses and usernames appropriately, and rifle other folks resources. As I pointed out yesterday, tickets can be replayed as long as they haven't expired. They can be replayed because a service cannot determine that the person sending the ticket is actually the ticket's legitimate owner. The service cannot make this determination because it does not share a secret with the user. Look at it this way. If I'm on watch at Elsinore, you know, the castle in Hamlet, and you are supposed to relieve me, I'm not supposed to let you take my place unless you can provide the correct password. That's the case where the two of us share a secret. And it's probably a secret that someone else made up for everyone who stands on watch. So I was thinking last night, why not have Charon make up a password for the legitimate ticket-owner to share with the service? Charon gives a copy of this session key to the service, and a copy to the user. When the service receives a ticket from a user, it can use the session key to test the user's identity.

Euripides: Wait a second. How is Charon going to give both parties the session key?

Athena: The ticket-owner gets the session key as part of the reply from Charon. Like this: She scrawls the following on a chalkboard: CHARON REPLY - [sessionkey|ticket] The service's copy of the session key comes inside the ticket, and the service gets the key when it decrypts the ticket. So the ticket looks like this: TICKET - {sessionkey:username:address:servicename:lifespan:timestamp} When you want to get to a service, the client program you start builds what I call an AUTHENTICATOR. The authenticator contains your name and your workstation's address. The client encrypts this information with the session key, the copy of the session key you received when you requested the ticket. AUTHENTICATOR - {username:address} encrypted with session key After building the authenticator, the client sends it and the ticket to the service. The service cannot decrypt the authenticator yet because it doesn't have the session key. That key is in the ticket, so the service first decrypts the ticket. After decrypting the ticket, the service ends up with the the following information: The ticket's lifespan and timestamp;

The ticket-owner's name;

The ticket-owner's network address;

The session key. The service checks to see if the ticket has expired. If all is well in that regard, the service next uses the session key to decrypt the authenticator. If the decryption proceeds without a hitch, the service ends up with a username and a network address. The service tests this information against the name and address found in the ticket, AND the name and address of the person who sent the ticket and authenticator. If everything matches, the service has determined that the ticket-sender is indeed the ticket's real owner. Athena pauses, clears her throat, drinks some coffee. I think the session key-authenticator business takes care of the replay problem.

Euripides: Maybe. But I wonder . . . To break this version of the system, I must have the proper authenticator for the service.

Athena: No. You must have the authenticator AND the ticket for the service. The authenticator is worthless without the ticket because the service cannot decrypt the authenticator without first having the appropriate session key, and the service cannnot get the appropriate session key without first decrypting the ticket.

Euripides: Okay, I understand that, but didn't you say that when a client program contacts the server, it sends the ticket and matching authenticator together?

Athena: Yes, I guess I said that.

Euripides: If that's what actually happens, what prevents me from stealing the ticket and authenticator at the same time? I'm sure I could write a program to do the job. If I've got the ticket and its authenticator, I believe I can use the two as long as the ticket has not expired. I just have to change my workstation address and username appropriately. True?

Athena: (Biting her lip) True. How dispiriting.

Euripides: Wait, wait, wait! This isn't such a big deal. Tickets are reusable as long as they haven't expired, but that doesn't mean that authenticators have to be reusable. Suppose we design the system so that authenticators can only be used once. Does that buy us anything?

Athena: Well, it might. Let's see, the client program builds the authenticator, then sends it with the ticket to the service. You copy both ticket and authenticator as they move from my workstation to the server. But the ticket and authenticator arrive at the server before you can send your copies. If the authenticator can only be used once, your copy of it is no good, and you lose when you attempt to replay your ticket and authenticator. Well, that's a relief. So all we have to do is invent a way to make the authenticator a one-time usable thing.

Euripides: No problem. Let's just put a lifespan and timestamp on them. Suppose each authenticator has a lifespan of a couple of minutes. When you want to use a service, your client program builds the authenticator, stamps it with the current time, then sends it and the ticket to the server. The server receives the ticket and authenticator and goes about its business. When the server decrypts the authenticator, it checks the authenticator's lifespan and timestamp. If the authenticator hasn't expired, and everything else checks properly, the server considers you authenticated. Suppose I copied the athenticator and ticket as they crossed the network. I have to change my workstation's network address and my username, and I have to do this all in a couple of minutes. That's a pretty tall order. In fact I don't think it's possible. Unless . . . Well, here's a potential problem. Suppose that instead of copying the ticket and authenticator as they travel from your workstation to the server, I copy original ticket packet that comes from Charon, the packet you receive when you ask Charon to give you a ticket. This packet, as I recall, has two copies of the session key in it: one for you and one for the service. The one for the service is hidden in the ticket and I can't get to it, but what about the other one, the one you use to build authenticators? If I can get that copy of the session key, I can build my own authenticators, and if I can build my own authenticators, I can break the system.

Athena: That's something I thought about last night, but then I traced the process of acquiring tickets and found that it wasn't possible to steal authenticators that way. You sit down at a workstation and use the kinit program to get your ticket-granting ticket. Kinit asks for your username, and after you enter it, kinit forwards the name to Charon. Charon uses your name to look up your password, then proceeds to build a ticket-granting ticket for you. As part of this process, Charon creates a session key that you will share with the ticket-granting service. Charon puts a copy of the session key in the ticket-granting ticket, and puts your copy in the the ticket packet that you are about to receive. But before it sends you this packet, Charon encrypts the whole thing with your password. Charon sends the packet across the network. Someone can copy the packet as it goes by, but they can't do anything with it because it has been encrypted with your password. Specifically, no one can steal the ticket-granting session key. Kinit receives the ticket packet and prompts you for a password, which you enter. If you enter the correct password, kinit can decrypt the packet and give you your copy of the session key. Now that you've taken care of the kinit business, you want to get your mail. You start the mail client program. This program looks for a mail service ticket and doesn't find one (after all, you haven't tried to get your mail yet). The client must use the ticket-granting ticket to ask the ticket-granting service for a mail service ticket. The client builds an authenticator for the ticket-granting transaction and encrypts the authenticator with your copy of the ticket-granting session key. The client then sends Charon the authenticator, the ticket-granting ticket, your name, your workstation's address, and the name of the mail service. The ticket-granting service receives this stuff and runs through the authentication checks. If everything checks properly, the ticket-granting service ends up with a copy of the session key that it shares with you. Now the ticket-granting service builds you a mail service ticket, and during this process, creates a new session key for you to share with the mail service. The ticket-granting service now prepares a ticket packet to send back to your workstation. The packet contains the ticket and your copy of the mail service session key. But before it sends the packet, the ticket-granting service encrypts the packet with its copy of the TICKET-GRANTING session key. That done, the packet is sent on its way. So here comes the mail service ticket packet, loping across the network. Suppose some network ogre copies it as it goes by. The ogre is out of luck because the packet is encrypted with the ticket-granting session key; you and the ticket-granting service are the only entities that know this key. Since the ogre cannot decrypt the mail ticket packet, the ogre cannot discover the MAIL SESSION KEY. Without this session key, the ogre cannot use any of the mail service tickets you might subsequently send across the network. So I think we're safe. What do you think?

Euripides: Perhaps.

Athena: Perhaps! Is that all you can say!

Euripides: (laughing) Don't get upset. You should know my ways by now. I guess it is mean of me, and you up half the night.

Athena: Pthhhhh!

Euripides: All right, three-quarters of the night. Actually, the system is beginning to sound acceptible. This session key business solves a problem that I thought of last night: the problem of mutual authentication.

Pause.

Mind if I talk for a minute?

Athena: (A trifle coldly) Be my guest.

Euripides: You are so kind. (Euripides clears his throat.) Last night, while visions of session keys and authenticators danced in your head, I was trying to find new problems with the system, and I found one that I thought was pretty serious. I'll illustrate it by way of the following scenario. Suppose you are sick of your current job and have determined that it is in your best interest to move on. You want to print your resume on the company's wizz-bang laser printer so that headhunters and potential employers can take note of your classiness. So you enter the printing command, and direct it to send the resume to the appropriate print server. The command gets the proper service ticket, if you don't already have it, then sends the ticket in your name to the appropriate print server. At least that's where you think it's headed. You don't in fact know that the request is headed for the right print server. Suppose that some unscrupulous hacker--say it's your boss--has screwed system around so that he redirects your request and its ticket to the print server in his office. His print service program doesn't care about the ticket or its contents. It throws away the ticket and sends a message to your workstation indicating that the ticket passed muster, and that the server is ready and willing to print your job. The printing command sends the job to the fraudulant print server and the enemy ends up with your resume. I'll state the problem by way of contrast. Without session keys and authenticators, Charon can protect its servers from false users, but it cannot protect its users from false servers. The system needs a way for client programs to authenticate the server before sending sensitive information to the service. The system must allow for mutual authentication. But the session key solves this problem as long as you design your client programs properly. Back to the print server scenario. I want a print client program that makes sure the service it's sending jobs to is the legitimate service. Here's what such a program does. I enter the printing command and give it a filename, the name of my resume. Assume that I have a print service ticket and session key. The client program uses the session key to build an authenticator, then sends the authenticator and ticket to the "supposed" print server. The client DOES NOT send the resume yet; it waits for a response from the service. The real service receives the ticket and authenticator, decrypts the ticket and extracts the session key, then uses the session key to decrypt the authenticator. This done, the service runs all the appropriate authentication tests. Assume the tests confirm my identity. Now the server prepares a reply packet so that it can prove its identity to the client program. It uses its copy of the session key to encrypt the reply packet, then sends the packet to the waiting client. The client receives the packet and attempts to decrypt it with my copy of the session key. If the packet decrypts properly and yields the correct server response message, my client program knows that the server that encrypted the packet is the real server. Now the client sends the resume job to the print service. Suppose my boss screwed around the system so that his print server poses as the one I want. My client sends the authenticator and ticket to the "print service" and waits for a response. The fake print service cannot generate the correct response because it cannot decrypt the ticket and get the session key. My client will not send the job unless it receives the correct response. Eventually the client gives up waiting and exits. My print job does not get completed, but at least my resume did not end up on the desk of the enemy. You know, I think we have a solid basis on which to implement the Charon Authentication System.

Athena: Perhaps. Anyway, I don't like the name "Charon."

Euripides: You don't? Since when?

Athena: I've never liked it, because the name doesn't make sense. I was talking to my Uncle Hades about it the other day, and he suggested another name, the name of his three-headed watch dog.

Euripides: Oh, you mean "Cerberus."

Athena: Bite your tongue Rip! "Cerberus" indeed . . .

Euripides: Er, isn't that the name?

Athena: Yeah, if you happen to be a Roman! I'm a Greek goddess, he's a Greek watch dog, and his name is "Kerberos," "Kerberos" with a K.