Kerberos principle-classic conversation

This is a set of dialogs written by MIT (mascript usetts Institute of Technology) to help people understand Kerberos principles. There are two fictional figures: Athena and Euripides. Through the constant conception of Athena and the constant search for vulnerabilities in Euripides, we can understand the principles of the Kerberos protocol.
Athena: Athena, goddess of wisdom and skill.
Euripides: the tragic poet of Greece.
The translation is as follows:
Scene 1
In a small work room. Athena and Euripides are working on adjacent terminals.
Athena: Hi, this time-sharing operating system is too slow. I couldn't work at all, because everyone got on.
Euripides: Do not complain to me. I only work here.
Athena: Do you know what we need? We need to give everyone a job so that everyone will not worry about the speed of the computer. In addition, we need a network to connect all computers.
Euripides: Good. So we need around one thousand workstations?
Athena: similar.
Euripides: Do you know how big a hard disk is for a normal workstation? No software can be stored there.
Athena: I already have an idea. We can place the system software on the server. When you log on to the workstation, the workstation will contact the system software on one of the servers through the network. This setting allows a group of workstations to use the same system software and facilitates the upgrade of system software. You only need to change the server.
Euripides: Okay. How can I handle my files? On a time-sharing operating system, I can log on and remove my files from the terminal. Can I fetch my files from my workstation? Do I need to put my files on a disk like a PC user? I hope not.
Athena: I think we can store files on other machines. You can log on to any machine to retrieve your files.
Euripides: What should I do when printing? Do I need a printer for each workstation? Who will pay? What about emails? How do you send emails to All workstations?
Athena: Ah... obviously we have no money to provide a printer for everyone, but we have a dedicated machine for printing services. If you send the request to the server, it will print it for you. Emails can also do this. There is a dedicated email server. If you want your email, contact the email server to pick up your email.
Euripides: your workstation system sounds good. If I have one, do you know what I want to do? I want to find out your username and make my workstation think that I am yours. Then I will go to the email server to get your email. I will link your file server, remove your file, and then --
Athena: Can you do it?
Euripides: of course! How do these network servers know that I am not you?
Athena: Well, I don't know. I think I need to think carefully.
Euripides: Okay. Tell me what you want.
Act 2
Euripides office, the next morning. Euripides sat at his desk and read his email. Athena knocks on the door.
Athena: I have come up with how to protect an open network system so that people as immoral as you cannot use network services with others' names.
Euripides: is it true? Sit down.
She sat down.
Athena: Can I make an agreement for our discussion before I start to describe it?
Euripides: What conventions?
Athena: Well, let me say this: "I want my mail, so I contacted the mail server and asked it to send the mail to my workstation. "Actually, I did not contact the server. I use a program to contact the server and get my mail. This program is the client of this service. But I don't want to say "How the client works" every time I interact with the server. I just want to say, "How do I do?" Remember, the client is doing everything on behalf of me. Can this happen?
Euripides: Of course. No problem.
Athena: Good. Then I will begin to explain the problems I have solved. In an open network environment, the machine providing services must be able to identify the entity requesting services. If I request my email from the email server, the service program must be able to verify that I am the person I stated.
Euripides: Yes.
Athena: you can solve this problem with a stupid method: the server asks you to enter your password. By using a password, I can prove who I am.
Euripides: That is really clumsy. In a system like that, every server must know your password. If the network has one thousand users, each server must have one thousand passwords. If you want to change the password, you must contact all servers to notify them to change the password. I think your system will not be so stupid.
Athena: My system is not that stupid. It works like this: not only do people have passwords, but also services have passwords. Each user knows their own password, and each service knows its own password. There is an authentication service that knows all the passwords, users' and services. The authentication service stores the password in a separate central database.
Euripides: Does this authentication service have a name?
Athena: I haven't thought about it yet. Do you want one?
Euripides: who sent the dead to the tunnel?
Athena: Charon?
Euripides: Yes, it is him. If he cannot confirm your identity, he will not send you across the river.
Athena: Do you want to rewrite Greek mythology. Charon doesn't care about your identity. He just determines if you are dead.
Euripides: Do you have a better name?
Stopped.
Athena: No. Actually, no.
Euripides: Well, let's take the certification service "Charon ".
Athena: Well, I guess I should describe this system, huh? For example, we want a service: mail. You cannot use a service in my system unless Charon tells the service that you are indeed the person you declare. In other words, you must get Charon certification to use the service. When you request authentication from Charon, you must tell Charon which service you want to use. If you want to use an email, tell Charon. Charon, please prove your identity. So you gave it your password. Charon compares your password with the password in its database. If they are equal, Charon considers that you have passed the verification. Charon now let the mail service know that you have passed the verification. Since Charon knows the password of all services, it also knows the password of the mail service. Charon gives you the email service password, and you can use this password to make the mail service believe that you have passed the verification. The problem is that Charon cannot directly give you the password because you will know it. Next time you want the mail service, you will bypass Charon to use the mail service without authentication. You can also pretend that someone is using the mail service. Therefore, instead of directly sending you the email service password, Charon will give you a "ticket" for the email service ". This ticket contains your name and the name is encrypted with the email service password. Once you get the ticket, you can request your email from the email service. You send a request to the email service and use your ticket to prove your identity. The Service uses its own password to decrypt the ticket. If the ticket can be correctly decrypted, the server will retrieve the username in the ticket. The service compares the name with the user name sent along with the ticket. If they match, the server considers that you have passed the verification and sends your email to you. What do you think?
Euripides: I have some problems.
Athena: I guess. Please.
Euripides: when the service decrypts a ticket, how does it know that it is correctly decrypted?
Athena: I don't know.
Euripides: Maybe you should include the service name in the ticket. In this way, when the service decrypts a ticket, it can determine whether the decryption is correct by finding its own name in the ticket.
Athena: Good. The ticket should look like this:
(She wrote the following on a piece of paper)
Ticket-{User name: Service name}
Euripides: Does the ticket only contain the user name and service name?
Athena: use the service password for encryption.
Euripides: I don't think this information can secure the ticket.
Athena: What does it mean?
Euripides: assume that you request a mail service ticket to Charon. Charon has a ticket with your name "Tina. Assume that I copied a copy of the ticket from Charon to you. Assume that I have convinced my workstation that my user name is "Tina". The email client considers me to be you. Use your name to send a request to the email server using a stolen ticket. The email server decrypts the ticket and considers it legal. The user name in the ticket matches the user name used to send the ticket. The email server will send me your email.
Athena: Oh! That's not good.
Euripides: But I have come up with a solution to solve this problem. Or partially solved. I think Charon should include more information in the ticket. In addition to the user name, the ticket should also contain the IP address of the user requesting the ticket. This adds security to you. Let me demonstrate it. Suppose I have stolen your ticket. This ticket has the IP address of your workstation, and this address does not match the address of my workstation. Use your name to send the stolen ticket to the email server. The service program extracts the user name and network address from the ticket and tries to match the user name and network address. The network address does not match if the user name matches. The server rejects this ticket because it is obviously stolen.
Athena: Hero! I did not expect it.
Euripides: Okay, this is what I want to express.
Athena: the ticket should look like this.
She wrote the following on the blackboard.
Ticket-{User name: Address: Service name}
Athena: I'm really excited now. Let's build a Charon system to see if it works!
Euripides: Not that fast. I still have some problems with your system.
Athena: Okay. (Athena leaned out of her chair) Say.
Euripides: It sounds like I have to get a new ticket every time I want to get a service. If I work all day, I may have to retrieve my emails more than once. Do I have to get a new ticket every time I get an email? If so, I don't like your system.
Athena: Ah... I don't understand why tickets cannot be reused. If I have obtained a ticket to the mail service, I can use it again and again. When the email client requests the service with your name, it transfers a copy of the ticket to the service.
Euripides: better. But I still have problems. You seem to imply that every time I use a service without a ticket, I have to give Charon my password to retrieve my files after I log on. I request my ticket to Charon, which means I have to use my password. Then I want to read my emails. Send a request to Charon again, and I will lose my password again. Now let's assume that I want to print my email. I have to send another request to Charon. Do you know?
Athena: Ah, yes, I understand.
Euripides: and if this is not bad enough, think about it: it seems like this. Every time you want to authenticate Charon, You need to transmit your password over the network in plain text. Smart people like you can monitor the network and get others' passwords. If I get your password, I can use your name to use any service.
Athena sighed.
Athena: there are indeed serious problems. I think I should go back to the design room.
Act 3
Early the next morning, Athena met Euripides in the coffee room. When Euripides poured coffee, Athena took a shot.
Euripides.
Athena: I have a new Charon version to solve our problem.
Euripides: is it true? So fast.
Athena: Well, you see, these problems have plagued me overnight.
Euripides: it must have been discovered by your conscience. Should we go to the small meeting room over there?
Athena: OK.
The two went to the small meeting room.
Athena: I want to re-describe the problem, but I want to convert it as needed.
Athena cleared his throat.
Athena: The first restriction: the user only enters the password once. When their workstation is started, this means that you do not need to enter your password when you need to apply for a new service ticket. The second restriction: passwords cannot be transmitted in plaintext over the network.
Euripides: Okay.
Athena: I started with the first restriction: you only need to enter your password once. I created a new network service to solve this problem. It is called the "ticket authorization" service, which gives the Charon ticket to the user. To use it, you must have a ticket: Ticket authorization ticket. The bill Authorization Service is only a version of Charon, which can access the Charon database. It is a part of Charon and allows you to pass the ticket instead of the password for authentication. In short, the authentication system now works like this: you log on to a workstation and use a kinit program to communicate with the Charon server. You prove your identity to Charon and the kinit program gets a ticket authorization ticket. Now you want to retrieve your email from the email server. You do not have a ticket to the email server, so you can use the "ticket authorization" ticket to get the mail service ticket. You do not need to use a password to get a new service ticket.
Euripides: Every time I want another network service, do I have to get a "ticket authorization" ticket?
Athena: No. Remember, we have agreed that tickets can be reused last time. Once you use the ticket authorization ticket, you can use it directly.
Euripides: Well, it makes sense. Since you can reuse a ticket, once you get a ticket for a service, you do not need to get it again.
Athena: Yes, isn't that good?
Euripides: Okay. I have nothing to say, as long as you do not transmit your password on the Internet in plain text when you get the ticket authorization ticket.
Athena: As I said, I have solved this problem. It sounds like, when I say I want to contact Charon to obtain the ticket authorization ticket, you need to transmit the plaintext password on the network. But this is not the case. Actually, when you use the kinit program to obtain the ticket authorization ticket, kinit does not send your password to the Charon server, and kinit only sends your username.
Euripides: Very good.
Athena: Charon uses the user name to find your password. Charon then groups a packet containing the ticket authorization ticket. Before sending it to you, Charon uses your password to encrypt the package. Your workstation received the package. Enter your password. Kinit uses your password to decrypt the package. If it succeeds, you will authenticate Charon. You now have a ticket authorization ticket. You can use this ticket to get other tickets. What are these whimsy?
Euripides: I don't know... I'm thinking. You know that part of your system works well. Your system only needs to be authenticated once. In the future, Charon will give me a ticket for service and I need to care about it. Seamless and seamless. However, the design of service tickets still bothers me. Service tickets can be reused. I agree that they should be reusable, but it is very dangerous to reuse service tickets because of their own nature.
Athena: What does it mean?
Euripides: see this. Suppose you are using an insecure workstation. After you log in, you need to mail service tickets, print tickets, and file service tickets. Suppose you accidentally leave those tickets after you quit. Now let's assume that I have logged on to the workstation and found the tickets. I wanted to make some trouble, so I logged on with your name. Since those tickets are your names, I can take your emails and type a large number of files. This is because these tickets were accidentally put there. I can also copy these tickets and use them forever.
Athena: But this is a good solution. We can write a program to destroy the tickets when the user exits, and the tickets cannot be reused.
Euripides: Obviously, you should have a ticket destruction program, which is very stupid for users to rely on. You cannot expect users to destroy tickets when they exit. You cannot even rely on the destruction of the ticket itself. I have a program that can monitor the network and copy service bills of others. Suppose I want to sacrifice you. When I arrive at the workstation, I open my program and copy your ticket. I will wait for you to exit and leave. I changed the address of my workstation to the address used for logon. I make the workstation think that I am you. I have your ticket, your username, and your address. I can use these tickets to use your service. Your ticket was destroyed when you left the workstation. These stolen tickets can be used all the time, because your current ticket does not have a certain validity period, or how long it can be used.
Athena: Oh, I understand what you said! A ticket cannot always be valid because it may be a big security risk. We should limit how long each ticket can take, and maybe we can set a validity period for each ticket.
Euripides: very correct. I want to add two items to the ticket: the lifetime indicates the validity of the ticket, and a time mark indicates when Charon issued the ticket.
Euripides goes to the blackboard and writes the following content:
Ticket {User name: Address: Service name: Validity Period: Timestamp}
Euripides: when the service unissues an invoice, it checks the user name and address of the ticket that matches the sender, and then uses the validity period and timestamp to check whether the ticket is valid.
Athena: Good. What is the validity period of a typical ticket?
Euripides: I don't know. It may be the work cycle of a typical workstation. Eight hours.
Athena: If I spend more than eight hours on the workstation, all the tickets will expire. Includes ticket authorization tickets. Then I will re-authenticate Charon in eight hours.
Euripides: Is it unreasonable?
Athena: I don't think so. Okay, let's make a decision. The ticket will expire in eight hours. Now I have a question to ask you. Suppose I copied your ticket from the Internet --.
Euripides: (blinking) Ah, Tina! You don't really do this, do you?
Athena: This is just for discussion. I copied your ticket. Now I am waiting for you to exit and leave. Suppose you have a doctor's appointment or gathering to attend. You quit two hours later and destroyed your ticket before exiting. But I have stolen your tickets and they can be used for six hours. This gives me enough time to fetch your files and print one thousand pieces of things in your name. You see, the timestamp works well if thieves choose to use it after it becomes invalid. If the thief can use it before it becomes invalid .... Ah, okay... of course, you're right.
Athena: I think we have encountered a big problem. (She sighed)
Stopped.
Euripides: I think this means you are busy tonight. How about coffee?
Athena: Why not.
Act 4
The next morning at the Euripides office. Athena.
Euripides: you have dark circles this morning.
Athena: Okay, you know. It's a long night.
Euripides: Have you solved the recurrence problem?
Athena: I think so.
Euripides: Please sit down.
She sat down.
Athena: Let me reiterate the question. Tickets can be reused within a limited period of time (eight hours ). If someone steals your ticket and uses it before it becomes invalid, we have no choice.
Euripides: Indeed.
Athena: we can understand this question as designing a ticket that others cannot reuse.
Euripides: But in this case, you will get a new ticket every time you use the new service.
Athena: Yes. But that is a stupid solution. (Paused .) Ah, how can I continue my discussion? (She pondered for a moment ). Okay. I want to repeat a question to see what is necessary. The Network Service must prove that the person who uses the ticket is the person stated on the ticket. I followed the authentication process again, so that I can demonstrate my solution. I want to use a network service now. I use it by starting a client on the workstation. The client sends three items to the server: my name, the network address of my workstation, and the appropriate service ticket. This ticket contains the name of the person applying for this ticket and the address of the workstation he or she used to apply for it. It also contains the validity period and timestamp of the ticket. All this information is encrypted by the Service password. Our current Authentication mode is based on the following tests: Can the service decrypt tickets? Is the ticket valid? Does the name and address in the ticket match the applicant's name and address? What have these tests proved? The first test proves whether the ticket is from Charon. If the ticket cannot be properly decrypted, it means that the ticket is not from the real Charon. The real Charon will use the service ticket to encrypt the ticket. Charon and service are the only two entities that know the service password. If the ticket is successfully decrypted, the service knows it comes from the true Charon. This test Prevents someone from forging a fake ticket. The second test checks whether the ticket is valid. If it expires, the service is rejected. This test blocks the use of old tickets because tickets may be stolen. Item 3 test whether the user name and address of the ticket match the user name and address of the requester. If the test fails, the user uses another person's ticket. Of course this ticket was rejected. If the name matches the address, what does this test prove? Nothing. The ticket can be stolen, and the user name and network address can be changed, if necessary. As I pointed out yesterday, tickets can be stolen within the validity period. Because the service cannot determine whether the ticket sender is a legal user. The service cannot be judged because it does not share a secret with users. In this case. If I am on duty in elströnor (Castle in hampir), you are planning to change to me. However, I will not change the course with you unless you have the correct password. We shared a secret. It may be set by someone for all on duty. So last night I was wondering why Charon cannot set a password between a legal user and a service? Charon sends a password to the service and a password to the user. When the Service receives a ticket from the user, it can use this password to verify the validity of the user.
Euripides: Wait. How does Charon send two passwords at the same time?
Athena: the owner of the ticket obtains the password from the Charon response, as shown in the following figure:
She wrote the following on the blackboard:
Charon response-[Password | ticket]
The Service obtains the password from the ticket. The ticket format is as follows:
Ticket-{password: User name: Address: Service name: Validity Period: Timestamp}
When you request a service, the client generates a 'validator '. The validators contain your name and the address of your workstation. The client encrypts the information with a password obtained when you request the ticket.
Authenticator-{User name: Address} is encrypted with a password.
After the validator is generated, the client sends it and the ticket together to the service. Because the Service does not have a password, it cannot decrypt the validators. The password is in the ticket, so the service unissues the invoice first. After invoicing, the service will get the following: Validity Period and timestamp of the ticket; Name of the ticket owner; network address of the ticket owner; and password. Check whether the ticket expires. If everything is normal, the Service uses a password to unauthenticator. If there is no problem with decryption, the service will get a user name and network address. The Service uses them to match the user name and network address in the ticket. If they are correct, the Service determines that the ticket sender is the real owner of the ticket.
Athena paused, cleared his throat, and drank some coffee. I think the password validator mechanism solves the issue of theft.
Euripides: Maybe. But I want... To attack this system, I must have a validator.
Athena: No. You must have both the validators and tickets. Without a ticket, the validators are useless. A password is required for unlocking the validators, and a password is required for service uninvoicing.
Euripides: Well, I understand. Do you mean that when the customer program contacts the service, it sends both tickets and validators?
Athena: Yes, that's what I mean.
Euripides: If so, what can prevent me from stealing the tickets and validators? I can write a program. If I have a ticket and validators, I can always use it until the validity period ends. I only need to change my user name and workstation address. Isn't it?
Athena: (biting her lip) Yes. So frustrated.
Euripides: Wait, wait! This is not difficult to solve. Tickets can be reused within the validity period, but that does not mean that the validators are reusable. Suppose we have designed a validators that can be used only once. Is that okay?
Athena: Okay, maybe. Let me take a look at it. The client program generates a validator and sends it together with the ticket to the service. Real tickets and validators come first than the ones you copied. If the validators can only be used once, your copy will become invalid. Ah, that's right. What I need to do now is to invent one and method so that the validators can only be used once.
Euripides: No problem. We put the validity period and timestamp above. Assume that each verification has a validity period of two minutes. When you want to use a service, the client will generate a validator, mark the current time, and send it together with the ticket to the service. The server receives the ticket and validators, and the server unlocks the validators to check the timestamp and validity period of the validators. If the validators have not expired and all other checks have passed, the server considers that you have passed the authentication. Assume that I copied A validator and a ticket over the network. I have to change the network address and user name of my workstation, which takes several minutes. That is a very demanding requirement. I don't think it is possible unless... Well, there is a potential problem. Assume that the ticket and validators are not copied in the network transfer. I copied an original Charon package, which is your response to the Charon request. There are two passwords in this package: yours and service. The service password is hidden in the ticket. I cannot get it, but what about the other one? Which one do you use to generate the validators? If I get the password, I will use it to build my own validators. If I can build my own validators, I will be able to break your system.
Athena: That's what I thought last night, but when I followed the ticket handling process, it was impossible to steal the validators. You sit down at a workstation and use the kinit program to get your ticket authorization ticket. Kinit requires the user name. After you enter the user name, kinit sends it to Charon. Charon to search for your password with your name, and then generates a ticket authorization ticket. As part of the processing, Charon generates a password that you share with the ticket Authorization Service. Charon sends you the password along with the ticket authorization ticket, and encrypts it with your password before sending it. Charon sends out the package. Someone has obtained the package, but they can't do anything because it is encrypted with your password. In particular, no one can steal the password of the ticket Authorization Service. Kinit received the ticket and asked you to enter your password. If you enter the correct password, kinit unlocks the package and retrieves the password. Now you pay attention to kinit processing and you can get your email. You open the mail client. This app looks for a ticket to the email service but does not find it (you have not received your email ). The client uses the ticket authorization ticket to apply for a ticket to the mail service. The client generates a validator for the ticket authorization process and encrypts the validator with the ticket Authorization password. The client sends the validator to Charon, the ticket authorization ticket, your name, the address of your workstation, and the email service name. The ticket Authorization Service received these items and passed the authentication check. If everything passes, the ticket Authorization Service will get the password shared with you. Now, the ticket authorization service generates a ticket for the mail service. In this process, a password is generated for sharing with the mail service. The ticket Authorization Service Packs these items and sends them to your workstation. There are tickets and passwords in the bag. Before sending packets, the ticket Authorization Service encrypts the packets with the ticket Authorization password. After the package is finished, the package is sent out. In this way, the mail service ticket package is sent over the network. Suppose someone on the network copies it. He unfortunately found that the package was encrypted using the password for ticket authentication. Since it cannot be decrypted, he cannot get the email password. Without a password, he cannot use any mail service ticket sent over the network. Now I think we are safe. What do you think?
Euripides: Maybe.
Athena: Maybe! Will you just say this!
Euripides: (Laugh) don't care. Now you should know how to handle the problem. I guess you and I both worked late last night.
Athena: Hum!
Euripides: Okay, it's midnight. In fact, this system seems completely feasible. The password solution solved a problem that I thought of last night: mutual verification.
Paused.
Can I talk about it?
Athena: (a little cold) Please.
Euripides: You are so nice. (Euripides cleared his throat.) last night, when the password and validators were transferred in my mind, I wanted to find out new problems with this system, I think I found a very serious problem. I will demonstrate it below. Suppose you are tired of your current job and decide to change one. You want to print your cover letter with your company's laser printer and send it to headhunters and other employers. So you enter the print command, command to get the service ticket, and then send the ticket to the printer. This is where you think it should be delivered. In fact, you do not know that your request is sent to the correct printing server. Suppose some shameless people, such as your boss, have adjusted the system and sent your request to the printer in his office. The Print Service does not care about the ticket content. It tells your workstation service that it is ready to print your files. The print command is sent to a fake printing server, and you are in trouble. I expressed the same problem in the opposite direction. With the password and validators, Charon can protect its servers against the use of wrong users, but it cannot protect its users from using wrong servers. The system needs to provide a method for verifying the server for the client program before it sends sensitive information to the server. The system must allow interactive verification. However, the password solution solves this problem. Let's go back to the print server scenario. I want to print out the client program to confirm that the service it delivers is a legal service. This is what the program is going to do. I enter the print command and give a file name. Now I have a service ticket and a password. The customer program generates a validator using the password, and then sends the validator and ticket to the hypothetical print server. The client has not sent a print file yet, and it is waiting for the return from the service. The real service receives the ticket and authenticator, decrypts the ticket and obtains the password, and unlocks the validator with the password. In this way, the server completes all authentication. The test has confirmed my identity. Now the service program has to prepare a response packet to verify its identity. It encrypts the returned packet with a password and sends the packet to the waiting client. The client received the package and tried to unbind it with a password. If the correct server response information is obtained after the packets are unwrapped, the client program will know that the server is a valid server. Then the client sends a print command to it. Suppose my boss changed the system so that his printer looks like the one I want to use. My client sent tickets and validators to it and waited for its response. The fake Print Service cannot generate the correct response because it cannot unbind the ticket and get the password. In this way, the client will not send a print command to it because the client does not get the correct response. Finally, the client stops waiting and exits. My print is not complete, but at least my cover letter will not be placed on my opposite desk. Well, I think we have a solid foundation for the Charon certification system.
Athena: Maybe. In any case, I don't like the name Charon.
Euripides: do you not like it? When?
Athena: I never liked it because it sounds meaningless. One day I talked about this with my Uncle heldis (Pluto). He recommended another name: the three-headed dog of Pluto.
Euripides: Ah, you mean "Cerberus ".
Athena: What language do you speak! "Cerberus" is actually...
Euripides: Oh, don't you call this?
Athena: Of course, who made you a Roman! I am a Greek, and it is a Greek watchdog. Its name is "Kerberos" and "Kerberos" is 'K.
Euripides: Okay, okay, don't get angry. I agree with this name. Actually, it has a good neck ring. Goodbye, Charon. Welcome, Kerberos.
Postscript
This conversation was written in 1988 to help readers understand how Kerberos V4 runs. After so many years, it is still very good service. When I converted this article into HTML, I was surprised to find that this document is still very useful for Kerberos V5. Although many things have changed, the core concepts have not changed. In fact, Kerberos V5 only makes two changes to Kerberos. The first change is because it is realized that the validators are valid for less than five minutes to prevent repeated attacks, if they use a program to automatically intercept votes and validators and repeat them. In Kerberos V5, The validators can only be used once because the server uses the 'replaying buffer' to save the information of the last submitted validators. If an attacker attempts to intercept the validator and reuse it, 'Repeat the buffer' will find that the validator has been submitted. The second major change is that when Kerberos sends a ticket to the kinit service, the ticket is no longer encrypted with the user's password. It has been encrypted using the password of the ticket Authorization Service. The ticket Authorization Service is directly transmitted when it is used to obtain other tickets. Therefore, you do not need to use your password to encrypt the ticket. (Other parts of the server response, such as passwords, are still encrypted with the user's password .) A similar change is also applied to the ticket Authorization Service protocol. Tickets returned from the ticket Authorization Service are no longer encrypted using the password of the ticket Authorization Service, because the ticket contained in the ticket has been encrypted by the password of the corresponding service. For example, the Kerberos V4 package is like this:
Kdc_reply = {ticket, client, server, k_session} k_user
The content in {} is encrypted by k_user.
Ticket = {client, server, start_time, lifetime, k_session} k_server
In Kerberos V5, kdc_reply now looks like this:
Kdc_reply = ticket, {client, server, k_session} k_user
(Note: The ticket is no longer encrypted using k_user)
Of course, there are many new features in Kerberos V5. Users can safely submit their tickets in another network. In addition, users can transfer some of their authentication permissions to the server so that the server can act as the user's proxy. Other new features include replacing the DES encryption algorithm with better encryption algorithms, such as triple DES encryption. If you are interested in V4 and V5 changes, you can read "the evolution of the Kerberos Authentication System" by Cliff norann and Theodore Tso. I hope you will be interested in this article about Kerberos protocol. I wish you further exploration in the future