Authentication system design classic session


Bill Bryant, first written in February 1988
Theodore ts’o was compiled and converted to HTML in February 1997, and an “after word” chapter was added to describe some changes in the V5 version


In this paper, we make up a dialogue about the construction process of Charon authentication system. With the dialogue going on, Athena and Euripides discussed the common security problems in the public network environment, and considered the solutions to these problems at the beginning of Charon system design. So Athena and Euripides didn’t really design the system until the conversation was complete.

When the system was designed, Athena changed the name of the system from Charon to Kerberos. Coincidentally, in Athena, a MIT project, the name of the authentication system designed and implemented is called Kerberos.

“Kerberos” in the dialogue has striking similarities with “Kerberos: an authentication system for public networks” published in 1988.

Scene I

In a cubicle, Athena and Euripides are working on two adjacent terminals

Athena: Rip, your timesharing system is a drag. Because everyone else was landing, it was so slow that I couldn’t do my job.

Euripides: Well, don’t complain to me. I’m just a part-time worker.

Athena: don’t you know what we need? What we really want is to give everyone a workstation of their own, and then use the network to link all the workstations so that people can communicate with each other, so that they don’t have to worry about sharing computing cycles.

Euripides: so how many workstations do we need, 1000?

Athena: almost

Euripides: have you ever investigated the disks of ordinary workstations? Generally speaking, there is not enough space to install all the software on your shared machine?

Athena: Well, I’ve already thought about that. We can install the required software on different servers. When you log on to your workstation, you can send requests to these servers through the network to use those software services. In this way, all workstations can use the same software version, and the software upgrade will be very convenient. Only the software on the server can be upgraded, and there is no need to operate on each workstation.

Euripides: OK, but how do you manage your personal files? In the time sharing system, I can log in and access my own files through any terminal connected to the system. After you design this way, can I get my personal files from any workstation, or do I have to take a floppy disk with me to save my own files?

Athena: I think we can use another server to store private files, so you can log on to any workstation to get your own files.

Euripides: what about the printing function? Should each workstation have its own printer? Whose money do you use to buy the equipment? And what about e-mail, how to distribute it to all the workstations?

Athena: Well Obviously, we don’t have the money to configure a printer for each workstation, but we can use a machine specifically for printing services. You send your printing task to the printing service machine, which will help you print. You can also use the same idea to process e-mail. A machine is dedicated to the e-mail service. If you want your mail, you can connect to this service and let him pick out your mail.

Euripides: your workstation system sounds great. When I have my own workstation, do you know what I will do? I will find out your name and make my workstation think I am you, so that I can connect to the mail service to get your mail, I can also connect to the file server to delete your files, I can also use

Athena: would you really do that?

Euripides: Yes, how can those services know that I’m operating instead of you?

Athena: Well, I don’t know. I need to think about it.

Euripides: that sounds like it. If you know how, please let me know.

Scene II

The next morning, in Euripides’ office, Euripides was reading his idea email at his desk when Athena knocked on the door

Athena: haha, I’ve found a way to encrypt the network environment so that naughty guys like you can’t pretend to be someone else to use those services.

Euripides: really? Sit down and talk.

Athena: before I start, can I set a basic rule for our discussion?

Euripides: what criteria?

Athena: if I said the following: “I want to see my email, so I connect to the mail service and tell the mail service to send it to my workstation.” In fact, it’s not that I directly connect to the mail service, but I use a program to connect to the mail service, a program called the mail service client.
But every time I describe the interaction between a user and a service, I don’t say “what the client did,” but “what did I do,” so remember that the client did these things as my proxy. Is there a problem with this?

Euripides: no problem.

Athena: the dumbest way to solve the problem of network security is to ask the user to provide a password to prove the user’s identity every time the mail service.

Euripides: that’s stupid enough. In such a system, every service needs to know your password. If there are 1000 users in the network, each service should have a password of 1000 users; when you want to change the password, you have to contact all the services to change them one by one. I don’t think your system is so stupid.

Athena: my system is not stupid. He works like this: it’s not just users who have passwords; services have passwords as well. Each user knows his own password, and each service knows his own password, and there is also an authentication service that knows all the passwords, including user’s and service’s. The authentication service stores these passwords in a central repository.

Euripides: did you give this certification service a good name?

Athena: I haven’t thought about it yet. Do you have any ideas?

Euripides: what about the name of the ferryman who helped the dead cross the Styx?

Athena: Charon?

Euripides: Yes, it’s him. He won’t ferry you unless you prove your true identity.

Athena: Rip, you’re doing this again. You’re making Roman mythology again. Charon doesn’t matter who you are. He just makes sure you’re dead.

Euripides: Well, do you have a better name?

Athena: No, not yet.

Euripides: call this service Charon.

Athena: Well, I’ll start describing the system.

Let’s assume you’re going to use mail now. In this system, you cannot use a service directly unless Charon tells the service that you are the person you claim to be. And you can’t get that service unless you authenticate with Charon first. When you authenticate with Charon, you also have to tell Charon which service you want to use, that is, if you want to use email service, you have to tell Charon explicitly.

Next, Charon asks you for authentication information. You provide Charon with your password, and Charon compares it with the password registered in the central database. If the password matches, Charon thinks you have confirmed your identity.

Next, Charon tells the mail service that you are the person you claim to be. Because Charon knows the passwords for all services, including mail services. Obviously, Charon can tell you the password of the mail service. When you make a request to the mail service, you can use this password to prove that you have authenticated with Charon.

The problem now is that Charon can’t give you the password directly, because after you know the password, the next time you want to visit the mail service, you can bypass Charon and no longer need to authenticate. After that, you can still disguise others and visit the mail service with other people’s names to get his mail.

So Charon will give you a ticket for your email service instead of a password. This ticket contains your name and will be encrypted with the password of the mail service.

TICKET = {username} K_server

  • {X}K_ Y means K_ Y encrypts X.

After you get the ticket, you can now request your email from the mail service. You tell the mail service your name and send the ticket to the mail service to prove your identity.

After receiving the bill, the mail service first decodes it with its own password. If it can be decoded normally, the mail service can get Charon’s name in the bill.

The mail service then compares the name in the bill with the name you provided. If the name is consistent, the mail service thinks you are the person you claim and sends your email to you.

What do you think of this method?

Euripides: I have a few questions.

Athena: as expected, you go on.

Euripides: when a service decodes a ticket, how does it judge that it has decoded it correctly (the ticket is for its own service, not the ticket for users to access other services)?

Athena: I haven’t thought about that yet.

Euripides: it’s better to put the name of the service in the ticket. In this way, when a service decodes the bill, it can judge whether the decoding is successful by finding his name correctly in the bill.

Athena: that sounds good, so now that’s what bills look like

TICKET - {username: servicename} K_server

Euripides: then the ticket contains the user name and service name.

Athena: encrypt with the password of the service.

Euripides: but I still don’t think this information can guarantee the security of the bill.

Athena: for example.

Euripides: for example, you ask Charon for a mail service ticket. Charon has the bill ready and put your name “Tina” in it. Suppose I made a copy of the bill when Charon sent it to you over the Internet, and then I cheated my workstation that I was Tina, so the mail client program working on my workstation would think I was you. Using your name, the email client then uses the stolen bills to send a request to the mail service. In this way, the mail service will decode the bill after receiving the request, and will verify it, and the mail service will send your service to me.

Athena: Well, yes, the design is still not perfect.

Euripides: but I know a way to fix it, or to fix it locally. I think Charon needs to include more information in the bill. In addition to the user name, Charon also needs to include the network address when the user requests the ticket, so as to provide an additional security guarantee.

I use the following process to prove: if I steal your ticket now, the ticket contains the address of your workstation, which is different from the address of my workstation. When I forged your name and the stolen bill to request the mail service, the mail service decoded the name and address from the bill and matched it with the user name and address in the request. Although the user name was successfully matched, the address did not match. Obviously, the bill was stolen and the server refused the request.

Athena: great. I hope I can think of it.

Euripides: ha, that’s what I’m trying to do.

Athena: so the modified bill becomes

TICKET = {username:ws_address:servicename} K_server

Athena: I’m so excited now. Let me build a Charon system to see if he can work.

Euripides: not so fast. I have a few questions about the system.

Athena: OK, go ahead.

Euripides: so far, every time I want to access a service, I have to get a ticket. If I work all day, I will definitely get my email information many times. If I had to get a ticket every time I visited the service, I would not like the system.
Athena: Well Why can’t the bill be reused? When you get a bill, you can reuse it. For example, when a mail client requests a service, it copies the ticket and sends it to the server.

Euripides: that sounds good, but there are still problems. For now, when I want to access a service that I don’t have a ticket for, I have to give Charon my password. For example, if I want to access my files, I have to provide Charon with my password to get a ticket. When I want to get my email from the mail service, I have to provide Charon with my password. If I want to print something, I have to visit Charon again. You can imagine that picture.

Athena: Well, yes.

Euripides: that’s not the worst. At the moment when you authenticate with Charon, you’re passing your password across the network in clear text. If I have your password, I can use any service in your name.

Athena: These are serious problems and I need to redesign them.

Scene III

The next morning, Athena met Euripides in the coffee shop. After he was filled with water, Athena put her hand on his shoulder and walked to the coffee machine

Athena: I thought a new version of Charon would solve our problem.

Euripides: really, so fast?

Athena: Well, this question made me think about it all night.

Euripides: it must be your guilt. Let’s talk about it in a cubicle?

Athena: why not?

They walk to a cubicle

Athena: as a start, I’ll restate our problem to see if our system really needs these features.

Athena: first requirement: users only enter their password once when they log in to the workstation. The requirement is that you don’t have to enter a password every time you get a ticket for another service. The second requirement: passwords cannot be transmitted on the network in clear text.

Euripides: Yes

Athena: for the first requirement: you only need to enter your password once. In order to meet this requirement, I will introduce a new service called “ticket granting”. When the user authenticates with Charon, the service will distribute tickets to the user. If you have a ticket (TGT) for this ticket distribution service, you can use the ticket distribution service.
The bill distribution service can be simply a variation of Charon, who also has access to a central database. The ticket distribution service in Charon allows you to authenticate with a ticket instead of a password.

Now, the authentication system will work like this: you log on to your workstation, and then use Kinit to connect to the Charon service. After that, you provide Charon with credentials, and Kinit gets your corresponding TGT from Charon service.

If you want to access the mail service now and you don’t have a mail service ticket, you can use TGT to get the mail service ticket from Charon instead of using a password to get the ticket.

Euripides: do I have to get a new TGT every time I need to access other services?

Athena: No, remember the last time we agreed that bills can be reused. Once you have a TGT, you don’t need to get another one, and then you can reuse the TGT to get tickets for other services.

Euripides: Well, that makes sense. Because you can reuse tickets, once the ticket distribution service gives you a service specific ticket (st), you don’t need to get the ticket again.

Athena: Yes, isn’t it simpler.

Euripides: Well, so far it’s OK, as long as my password is not transmitted over the network in clear text when getting TGT.

Athena: like I said, I solved my problem. In fact, when I asked Charon for TGT, I said as if I wanted to send your password over the Internet, but it wasn’t necessary.

The truth is, when using Kinit to get TGT from Charon, Kinit doesn’t send the password to Charon service, Kinit just sends your name.

Euripides: good

Athena: the Charon service uses your name to find your password. Then Charon constructs a packet containing TGT. Before Charon sends the packet to you, he encrypts the packet with your password.

After receiving the packet, your workstation will prompt you to enter the password. Kinit will try to decode the packet with the password you entered. If the decoding is successful, it indicates that your authentication is successful, and you will have TGT. Then you can use this ticket to obtain the ticket you want to serve.

Is this what you want?

Euripides: I don’t know yet. I need to think about it again. I think the part of the system you just described works very well. It only needs me to authenticate once. After that, Charon will automatically distribute tickets for other services to me, and I don’t need to care about it any more. But I am still confused about the design of the bill, because based on one premise, that is, the bill can be reused. I agree that the bill can be reused, but reusability is essentially dangerous.

Athena: specifically

Euripides: for example, if you use an insecure workstation, you get mail service tickets, print services, file services, and then you quit the workstation.

Now suppose I also log in to this workstation and find the tickets. As for me, I prefer to make trouble, so I changed my name to yours to deceive the workstation that I am you, because those bills are generated with your name, so I can use the email client to get your mail, get your files, and send thousands of printing tasks with your account. All of this is because you forget the bill On this workstation.

And there’s no way to stop me from copying them so I can use them all the time.

Athena: that’s a good solution. We can write a program to destroy the user’s ticket when the user logs out, so that you can’t use it.

Euripides: Well, obviously your system needs a destructor, but it’s stupid for users to rely on such a program. You can’t ensure that the user will execute the destruction procedure every time he / she logs out using the completion workstation. Even if you rely on the user to execute the destruction procedure, there will be problems in the following scenario

I wrote a program that can listen to the network and copy it when there is a service ticket coming out of the network. If I want to frame you up, when you log in to the workstation, I also open this program, so that I can copy your ticket.

When you finish your work, exit the workstation and leave, I change my workstation address into your address, change the user name to make my workstation believe that I am you, so that I have your ticket, your name, your address, and I can reuse these tickets in your name.

Even if you destroy your bills when you log out, it doesn’t matter, because the bills I stole will always be valid as long as I want to use them. And this is because there is no limit on the number of times or time of use of the bills in your current bill design.

Athena: Oh, I know what you’re saying. Perpetual validity of bills is a big security risk. We have to limit the maximum length of time that a ticket can be used. Maybe we can give each bill some overdue information.

Euripides: in fact, I think each bill has to be appended with the following information: a lifespan field indicating the maximum effective time of the bill; and a timestamp field indicating when Charon created the ticket. So now the bill information becomes

TICKET = {username:ws_address:servicename:lifespan:timestamp} K_server

Euripides: now, after a service decodes the bill, first check whether the user name and address in the ticket are consistent with the one sent by the user, and then use the validity period and timestamp fields to determine whether the bill has expired.

Athena: good. How long is the validity set?

Euripides: I’m not sure. How long is the session set up for most workstations, that is, eight hours?

Athena: that is to say, if I work on my workstation for more than eight hours, all my tickets will be invalid, including the ticket distribution tickets, so after eight hours, I have to authenticate with Charon again.

Euripides: isn’t that hard to accept?

Athena: Well, it is. Then we’ll make it clear that the bill will expire in eight hours. Now I have a new question. If I copy your bill from the Internet

Euripides: Oh, Tina, you don’t really do that, do you.

Athena: it’s just a hypothetical scenario for our conversation. Now I copy your ticket and wait for you to exit your workstation. Maybe you have an appointment with your doctor or attend a meeting, so you quit your workstation in about two hours. Although you are more careful to destroy your bills when they are launched, I have stolen them and they will be available for the next six hours. I will have enough time to manipulate your files and send thousands of print jobs in your name.

Therefore, the method of appending validity period and time stamp is effective for the attack after the bill has expired, but if it is attacked before the expiration of the bill..

Euripides: Oh, yes, you are right.

Athena: I think we’ve got the core problem.

Euripides: I guess you’re busy again tonight. Are you going to have some coffee?

Athena: Yes, let’s go

Scene IV

The next morning, in Euripides’ office, Athena knocked on the door and came in

Euripides: Tina, I’ve been wearing dark circles all morning.

Athena: Yeah, you know another long night.

Euripides: have you found a way to solve the problem?

Athena: I think I found it.

Euripides: sit down and speak slowly.

Athena: as usual, first of all, I’d like to repeat this question: all bills have a validity period of – 8 hours. If someone steals your bill before it’s due, we can’t stop him.

Euripides: that’s exactly the problem

Athena: if we make the bill non reusable, then we can fix it

Euripides: but then you have to ask for a ticket every time you want to use a web service

Athena: Yes, it’s a crude solution. Oh, how can I go on with my argument?
Well, let’s recapitulate the problem from the perspective of requirements: a service must prove that the person who initiated the request with the ticket is the one Charon assigned the ticket to.

Let’s go through the certification process again and see if I can come up with an appropriate way to present my solution.

When I want to access a specific service, the first step is to start a client program on my workstation. The client sends three messages to the service, my name, address, and corresponding tickets. The bill contains the user name of the authentication, the network address of the workstation corresponding to the authentication, and the expired information of the bill. All this information is encrypted with the password of the corresponding service when returned to the client.

Our current authentication model is based on the following tests:

  • Can the service decode the corresponding ticket
  • Is the bill overdue
  • Do the user name and network address in the ticket match the user name and address sent with the ticket

What can these tests prove?

First, whether the bill was distributed by Charon. If the bill can’t be decoded correctly, it’s not from the real Charon. The real Charon encrypts the service’s corresponding password, and only Charon and the service know the password of the service. If the ticket can be decoded properly, the service can determine that the ticket is from the real Charon, thus preventing attackers from forging Charon distribution tickets.

Second, whether the ticket has expired. If it does, the server will refuse the request, which can prevent the attacker from using the old tickets, which are likely to be stolen.

Third, check the user name and network address in the ticket. If the check fails, it indicates that the user is using someone else’s bill (possibly secretly), and the server must refuse such a request.

If the user name and address match, what does that prove? Nothing. An attacker can steal tickets from the network, change his workstation address and user name, and steal other people’s resources. As I said yesterday, bills can be reused indefinitely before they expire. They can be reused because the server can’t tell whether the user who is requesting is the real owner of the ticket.

The reason why the server can’t distinguish is that there is no shared confidential information between the server and the user. For example, I’m standing guard at Elsinore, and now you’re going to replace me. Unless you tell me the correct code, I won’t agree with you to replace me. This is an example of the need to share a secret between the two of us. The secret may be a secret that someone has come up with for all the watchmen.
That’s what I thought last night. Why can’t Charon generate a shared password for the real owner and service of the ticket? Charon sends a copy of the session key to the server, and then sends another copy to the user. When the server receives the user’s request, he can use the session key to authenticate the user.

Euripides: wait a minute. How does Charon send this key to the server and the user?

Athena: Charon takes the session key as part of the return value, like this:

CHARON REPLY = {sessionkey|ticket} K_user

The server obtains the session key by decoding the ticket, so the ticket now looks like this

TICKET = {sessionkey:username:address:servicename:lifespan:timestamp}K_server

Now when you want to access a service, the client program you use builds what we call an “authenticator,” which contains your user name and the network address of your workstation. The client encrypts the authentication object with the session key returned by Charon, which is the corresponding session key when he authenticates to Charon.

AUTHENTICATOR - {username:address} K_session

After the client has constructed the authentication object, it will be sent to the server together with the bill. At this time, the server can not decode the authentication object because it has not got the callback key and the key is stored in the bill. Therefore, the server must decode the bill first

After decoding the ticket, the server will obtain the following information:

  • Bill effective time and creation time
  • Name of the owner of the note
  • Network address corresponding to bill owner
  • session key

The server first checks whether the bill has expired. If it is good, then the server decodes the corresponding authentication object with the session key. If it can be decoded successfully, the server will obtain the user name and network address, and then the server will compare the obtained user name and network address with the corresponding information in the ticket, and then send it together with the bill and authentication object Compare the user name with the network address. If everything is correct, the server can confirm that the person who sends the bill is indeed the owner of the bill

In my opinion, session key authentication object can solve the problem of bill reuse

Euripides: maybe, I’m still confused. To use this method, I have to build the authentication object corresponding to the service

Athena: No, you need not only the authentication object, but also the correct ticket. If there is no ticket, only the authentication object is meaningless, because you can’t get the session key before decoding the ticket, and you can’t decode the authentication object without the session key.

Euripides: I know that, but you also said that when a client program requests the server, it will send the authentication object along with the ticket

Athena: Yes, I said that

How do you stop euride and me from stealing the ticket? I’m sure I can do this through the program. If I can steal the authentication object and the ticket at the same time, then I can use these two information to change the address and user name of my workstation to disguise the request before the bill expires, right?

Athena: Yes, I’m so disappointed

Euripides: wait, it’s no big deal. The ticket can be reused before expiration, but this does not mean that the authentication object can also be reused. If we design a scheme that only allows authentication objects to be used once, is there no problem

Athena: Yes, probably. Let’s talk about this process again. The client builds an authentication object and sends it to the server along with the ticket. You have copied and stolen a copy of the ticket and authentication object, but the ticket and authentication object have arrived at the server before you can send it to the server. If the authentication object can only be used once, the ticket and authentication object you copied will not work, and you will fail when you try to authenticate

OK, I’m relieved, so what I need to do now is to ensure that the authentication object can only be used once

Euripides: no problem. Let’s also store a validity period and generation time in the authentication object. Suppose that the validity period of each authentication object is only a few minutes. When you want to use a service, your client builds an authentication object, adds the current timestamp, and sends it to the server.

After receiving the ticket and the authentication object, the server decodes the ticket to obtain the session key, then decodes the authentication object with the session key, and then checks whether the authentication object has expired. If not, and other checks are passed, the server passes the authentication.

If I copy your ticket and authentication object now, in order to use them, I need to modify my workstation network and user name in a few minutes. This requirement is very high. I don’t think it can be done unless

Well, there is also a potential risk. If I do not copy the ticket and authentication object when you authenticate with the server, but copy the original packet that Charon sent you, which is the packet returned to you when you ask Charon for the ticket

This packet contains two session keys, one for you and one for the server. The one for the server is in the bill, which I can’t get. But what about the other one? What about the key you use to generate the authentication object

If I can get the key, I can build my own authentication object so that I can break the system

Athena: I thought about that last night, but I deduced the process of getting the ticket and found that it is impossible to steal the authentication object in this way.

You sit in front of your workstation and use the Kinit program to get your TGT. Kinit needs your name, and after you type it, Kinit sends it to Charon.

Charon uses your name to query your password in the database, and then creates a TGT. As part of this process, Charon creates a session key that you share with the ticket distribution service. Charon puts one copy of the key into the TGT and another into the packet. Before sending the packet to you, Charon encrypts it with your password.

CHARON REPLY = [sessionkey|TGT] K_user

Charon sends the encrypted data to you through the network. If someone steals the packet, without your password, he can’t decode the packet and get the session key.

After Kinit gets the packet, it prompts you to enter the password. If you enter the correct password, Kinit will decode the packet and give you the corresponding session key.

The client creates an authentication object for the bill distribution request and encrypts the authentication object with the session key. Then the client sends the encrypted authentication object to Charon, and sends TGT, your name, network address of the workstation and the name of the mail service you want to access,

The bill distribution service (TGs) receives these messages. (there is no difference between TGT and common St. it is the bill st corresponding to the bill distribution service, which also contains {s essionkey:username : address:servicename : lifespan:timestamp }This information is just the name of the fixed TGS and encrypted with the corresponding password of the bill distribution service.) If the check is passed, the ticket distribution service (TGs) will get a correct session key, and then the ticket distribution service will build a bill for you and the mail service Create a new shared session key.

Next, the ticket distribution service will prepare a ticket packet to send to your workstation, which contains the ticket of the newly created mail service and the newly created session key shared by you and the mail service. Before sending the packet, the ticket distribution service will encrypt the packet with the session key shared between you and the ticket distribution service.

Now let’s take a look at the sending of the bill packet of the mail service. If someone copies a copy of the packet in the project of transmitting it on the network, because the packet has been encrypted with the session key of the data distribution service, he can not get the session key of the mail service in the packet. Without this key, he can not create an authentication object The TGS does not generate mail through the network service.

So now we’re safe. What do you think?

Euripides: maybe

Athena: maybe, that’s all you have to say

Euripides: don’t be angry. It’s just a mean statement to me. You’ve been doing this all night


Euripides: Well, it’s 3 / 4 nights. Now, the system sounds acceptable. The way of session key solves a problem I thought about last night, a two-way authentication problem. Do you mind if I say a few more minutes?

Athena: sure

Euripides: you are so kind. Last night, when the session key and authentication object jumped into the brain, I tried to find a new problem in the system. Finally, I found a serious problem. Next, I will explain it with an example

If you are tired of your present job, and also find a new interest, want to change jobs in the past. You want to print your resume on the company’s printer so that headhunters or potential employers can notice your strengths.

So you click the print function and send your resume directly to the corresponding printer. If you don’t have a ticket for the print service, the print client will first get the ticket for the print service, and then send it to the server in your name. At least if you think it works according to this process, you don’t know whether the task has been sent to the correct printer.

If there are malicious hackers now – your boss – has a conversion system that can redirect your requests and tickets to his office printer. If the printer service is not designed to care about the corresponding ticket and content, it will directly ignore the ticket and return a message to your workstation saying that the ticket has been verified and the server is ready to provide printing service for you. The client will get your resume and send it to the printer.

I repeat this problem in a comparative way. Charon can prevent the server from being accessed by the wrong user, but it can’t prevent the user from accessing the wrong server when there is no session key and authentication object. The system needs a way for the client to verify the correctness of the server before sending sensitive information to the server, that is to say, the system must be able to authenticate both ways.

Using session key, as long as you can correctly design the client program, you can solve this problem. Let’s take the printing service as an example. We hope that the printing client can confirm that the printing service it sends is actually received by the correct printing service.

Then the printing client should do this. I input a print task and the corresponding print file name – the name of my resume. If I have the ticket and session key of the printing service, the client program uses the session key to build an authentication object and send the authentication object and ticket to the printer that thinks it is correct. At this time, the client did not send the resume to be printed, he had to wait for the server to return the information.
Now the real print service receives the ticket and authentication object. First, decode the ticket to obtain the session key, then decode the authentication object with the session key, and then do various authentication checks;

If the authentication is passed, the server will return a packet that can prove its identity to the client and encrypt the returned packet with session key.

After receiving the packet, the client attempts to decode the packet with the session key. If the packet is decoded correctly and the correct server return information is obtained, the client can determine that the information returned is the correct print service, and then the corresponding resume printing task will be sent.
Suppose your boss disguises his printer as the one I want to use with the conversion system. My client sends him authentication objects and tickets and starts waiting for the results to return. The masquerade printer cannot generate the correct return information because it cannot decode the ticket to get the session key. At this time, my client does not receive the correct return information, so it will not send the real printing task. Finally, the client waits for timeout and exits. Although my printing task is not completed, at least my resume does not appear on the enemy’s desk.

You see, we have a solid theoretical basis to implement the Charon authentication system.

Athena: Yes. But anyway, I don’t like the name Charon

Euripides: you don’t like it. When did it start

Athena: I don’t like it all the time because it doesn’t make any sense. I talked to my uncle about it before and he suggested that I use another name, Charon’s three headed dog

Euripides: Oh, you mean “Cerberus”

Athena: pay attention to your pronunciation. It’s “Cerberus.”

Euripides: Well, is that the name?

Athena: Yes, if you’re a Roman, I’m a Greek god, and I have a Greek watchdog, its name will read “Kerberos” with the initials K

Euripides: Well, don’t throw thunderbolt any more. Use that name. In fact, he has a beautiful black eye ring. Now, goodbye, Charon. Hello, Kerberos.


This dialogue was written in 1988 to help readers understand why the Kerberos V4 version was designed to look like this, and over the years, it has done a good job.

I was surprised to find that the same applies to this HTML version of the dialog. Although many things have changed, the core of the agreement remains the same. There are only two areas where adjustments have been made in V5.

The first change is to realize that if a hacker uses a program to grab tickets and authentication objects and send them to the server immediately, setting the validity period of authentication objects to 5 minutes does not effectively prevent this replay attack.

Therefore, in V5 version, the authentication object is really designed to be “only used once”. This is achieved by designing a cache on the server side to store the records of the recently sent authentication objects. The attacker tries to steal the authentication object and reuse it. Even in the 5-minute window, the server-side cache can distinguish that the authentication object has been submitted.

The second major change is that when a user uses Kinit to obtain a ticket (TGT) from Kerberos for the first time, the ticket does not need to be encrypted with the user’s password when Kerberos returns the ticket to the client. Because this ticket has been encrypted with the ticket distribution service password, and then users request tickets for other services from Kerberos with this ticket, it is also spread directly on the network in unencrypted form. Therefore, there is no need to encrypt the user’s password in this place (other parts of the returned packet, such as the ticket session key, should be encrypted)

The bill distribution service (TGs) has also been modified. The bill generated by the bill distribution service is no longer encrypted with the session key corresponding to the bill distribution service, because the ticket has been encrypted with the corresponding password of the service.
For example, in the V4 version, the packet looks like this

KDC_REPLY = {TICKET, client, server, K_session}K_user
TICKET = {client, server, start_time, lifetime, K_session}K_server

It will look like this in V5

KDC_REPLY = TICKET, {client, server, K_session}K_user

The final request process is as follows

Of course, Kerberos has added other new features in V5. Users can safely distribute their tickets for use elsewhere; users can also grant part of their permissions to a server, which can act as their own agent. Other new features include replacing DES with more secure encryption algorithms, such as triple des. If you want to know more about the differences between V5 and V4, you can visit [evolution of Kerberos system] by Cliff Neumann and Theodore ts’o.

Finally, I hope you like the brief introduction of Kerberos. I wish you all the best in your future use.

Theodore Ts’o 1997.2